[dojo-contributors] Parser Enhancements

Kitson Kelly kitson.kelly at asseverate.co.uk
Tue Jun 12 18:13:19 EDT 2012


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<http://bugs.dojotoolkit.org/attachment/ticket/15367/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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120612/ec436b73/attachment-0001.htm 


More information about the dojo-contributors mailing list