[dojo-contributors] Parser Enhancements

Kitson Kelly kitson.kelly at asseverate.co.uk
Tue Jun 12 01:42:08 EDT 2012

Ok, where I ended up with this is:
 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120612/c1d2dc35/attachment.htm 

More information about the dojo-contributors mailing list