[dojo-contributors] Parser Enhancements

Ben Hockey neonstalwart at gmail.com
Wed Jun 13 00:54:02 EDT 2012


thanks for the experiment files - they were very helpful for getting me up and running quickly.

i've sent you a pull request (https://github.com/kitsonk/util/pull/1) that shows how i thought this might work.  

the big advantage with this approach is that a single build can generate multiple layers that include declarative dependencies.  i would think that this approach would also have the least learning curve for anyone already familiar with how to add modules to layers.  essentially, each declarative resource can be thought of as a module and included or even excluded in a layer just like any other module.  the only burden on the end user is to properly tag their declarative dependencies and include those in any layers as needed.

let me know what you think.

thanks,

ben...

On Jun 12, 2012, at 6:13 PM, Kitson Kelly wrote:

> I have pushed one of my experiments to: https://github.com/kitsonk/buildtest.  I have another one that is a demo app that uses auto-require and declarative require as well.
> 
> The patch is included in my branch at: https://github.com/kitsonk/util
> 
> I could be missing something.  I don't think adding things to the include array would work.  Even if it did, it is a bit "clunky" IMO.  I think the bit of assigning the layer at the tag level might work.  Of course the original path I took was based off of offline feedback with Rawld (although in fairness it might have been my interpretation of his feedback).  I am not overly precious about anything and appreciate the input!
> 
> On 12 June 2012 14:56, Ben Hockey <neonstalwart at gmail.com> wrote:
> i don't want to intentionally block this from 1.8 but i need to prove to myself that it can't be done by specifying module ids in the include array of a layer.  i'd rather not have the builder need to understand yet another flag and i don't like the "magic" of defaulting to dojo/dojo.  do you have some test page you've been using for testing this so i can take a shot at making it work how i think it should?
> 
> var profile = {
> 	layers: {
> 		'app/main': {
> 			include: ['app/page.html']
> 		}
> 	},
> 
> 	resourceTags: {
> 		declarative: function (filename, mid, module) {
> 			return /\.htm(l)?$/.test(filename);
> 		}
> 	}
> };
> 
> every flag we add to a build is extra baggage we need to carry around.  even though this is low risk, once it lands it needs to stick around so i'd rather not add it at all if we can do better.
> 
> thanks,
> 
> ben...
> 
> 
> On Jun 12, 2012, at 1:42 AM, Kitson Kelly wrote:
> 
>> Ok, where I ended up with this is: declarativeDeps.3.patch.  It is sort of in line with what you suggested Ben, but was more simplistic.
>> 
>> Essentially you mark a layer as the declarativeIncludes layer and the dependencies are added there, or if there are resources marked as declarative, but no layer is flagged, they get built into "dojo/dojo".  So something like this would work:
>> 
>> var profile = {
>>   layers: {
>>     "app/main": {
>>       include: [],
>>       declarativeIncludes: true
>>     }
>>   }
>> 
>>   resourceTags: {
>>     declarative: function(filename){
>>       return /\.htm(l)?$/.test(filename);
>>     }
>>   }
>> };
>> 
>> The advantages of this versus something more complex is that in its most simplistic version, you simply mark resources as declarative and they get scanned for dependencies.  Also, adding them to a specific layer is easy as well.  The only thing it doesn't accomodate is saying "these resources go in this layer and these resources go in that layer".  I couldn't think in my mind of a clean way of expressing that, though I am now confident I could code it up.
>> 
>> I would like to try to get this in before the feature freeze for 1.8.  It is low risk in my opinion because it will only trigger when resources are tagged as something that didn't exist previously.
>> 
>> On 16 May 2012 22:01, Kitson Kelly <kitson.kelly at asseverate.co.uk> wrote:
>> 
>> 
>> On 16 May 2012 20:52, Ben Hockey <neonstalwart at gmail.com> wrote:
>> an idea…
>> 
>> do the declarative resources get a module id or have some way to reference them in the definition of a layer?
>> 
>> layers: {
>>   "my/declarative/layer": {
>>     declarative: [
>>       "my/resources/foo.html",
>>       "my/resources/bar.html"
>>     ]
>>   }
>> },
>> 
>> you can then process the "declarative" array with some logic that understands these declarative ids?  it's been a while since i've dug into the build transforms so i can't remember if i'm asking the impossible or not.  it would seem this approach would rather cleanly answer all of your questions:
>>  - no need for a buildDeclarativeLayer option, the presence of a declarative array in a layer definition is that trigger
>>  - no need for a module it, it comes from the id of the layer
>>  - as above
>> 
>> in addition, this would allow someone to potentially build multiple declarative layers - e.g. a multi-page site that wanted a unique declarative layer per page with a base layer that's included on all the pages.  it opens up the possibility of leveraging include and exclude for layers etc.
>> 
>> 
>> Right now a declarative build profile would look something like this:
>> 
>> var profile = {
>> 
>>     buildDeclarativeLayer: true,
>> 
>>     layers: {
>>         "dojo/dojo": {
>>             include: [ "dojo/dojo", "parserAutoRequire/src" ],
>>                 customBase: true,
>>                 boot: true
>>         }
>>     },
>> 
>>     resourceTags: {
>>         declarative: function(filename){
>>             return /\.htm(l)?$/.test(filename);
>>         },
>>         amd: function(filename, mid){
>>             return /\.js$/.test(filename);
>>         }
>>     }
>> };
>>  
>> I think leveraging the tagging mechanism makes the most sense.  I need to check though on how the layers are handled internally...  Adding a new property might be more heavy lifting on the internals of the buildController than it stands right now.  I would personally like to have something that said "build these dependencies into this layer" and "these into that" but the path Rawld and I came up was the this.  I like your idea Ben, it is just that I can't see the "path" of how to accomplish it at the moment, so I will do some more thinking.
>> 
>> I have attached my not fully complete, but working patch here: http://bugs.dojotoolkit.org/attachment/ticket/15367/declarativeDeps.patch for additional feedback.
>> 
>> 
>> _______________________________________________
>> dojo-contributors mailing list
>> dojo-contributors at mail.dojotoolkit.org
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> 
> 
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> 
> 
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120613/bdb3169c/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120613/bdb3169c/attachment.sig 


More information about the dojo-contributors mailing list