[dojo-contributors] Parser Enhancements

Christophe Jolif cjolif at gmail.com
Wed Jun 13 16:20:44 EDT 2012


I have not looked at the details but I agree that the build system is
complex enough to learn & configure so anything that would avoid
adding more complexity is welcomed to me.

On Wed, Jun 13, 2012 at 6:54 AM, Ben Hockey <neonstalwart at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>



-- 
Christophe


More information about the dojo-contributors mailing list