[dojo-contributors] Parser Enhancements

Ben Hockey neonstalwart at gmail.com
Tue Jun 12 09:56:44 EDT 2012


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120612/192da368/attachment-0001.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/20120612/192da368/attachment-0001.sig 


More information about the dojo-contributors mailing list