[dojo-contributors] Dojo 1.7 Goals: has() and granular dependency lists

Bill Keese bill at dojotoolkit.org
Tue Mar 15 01:30:51 EDT 2011

Rawld - thanks for working on this, let's definitely talk about it in the
weekly meeting (Wednesday for you).

I don't think there's anything to debate besides the has() stuff, which we
definitely haven't come to any conclusion on yet (see
despite Kris trying to push ahead with his preference.

On Tue, Mar 15, 2011 at 3:41 AM, Rawld Gill <rgill at altoviso.com> wrote:

> I'm working on the 1.7 bootstrap (as discussed at the 2 Mar meeting) and
> this
> work addresses some of the goals Kris outlined. I'll try to get something
> for
> everybody to look at by the next meeting [i've been pulled away from this
> work
> with another issue, but still hopeful on this timetable].
> I'll give an outline of this work below. You'll see that there are lots of
> design decision points.  My idea here is to get something working and then
> we
> can debate any critical decision points and modify code accordingly. I'm
> using
> my best judgment at each point, but *not* saying "this is the way it will
> be".
> Here are the main points of the design/impl:
> Bootstrap:
> Today, we have a single bootstrap, dojo.js, that is used for various
> environments (browser, rhino, etc.). This will be replaced with
> environment-
> specific bootstraps. We can decide the names later, but, for example:
>  1. dojo.js: generic browser hosted dojo that includes AMD loader and back
> compat layer to sync load via dojo.provide/require.
>  2. main-browser: generic browser hosted dojo that can be loaded by any AMD
> loader; I'll ensure that RequiresJs and bdLoad work.
>  3. main-node: node-hosted dojo that can be loaded by AMD loader in node.
>  4. etc.
> Granularity: (this dovetails with Kris's goals)
> Today, the boot sequence includes lots of functionality that is not
> possible
> to exclude. The big ones are the sync loader, DOMContentLoaded
> detection/processing, unload detection/processing, and browser sniffing.
> But
> there's also small stuff like console guarantee, OpenAjax registration,
> etc.
> Each chunk of functionality must be bracketed in a way that it can be
> excluded. There are three ways to bracket code:
>  * pragmas--I want to avoid these
>  * has.js
>  * separate AMD module
> I am refactoring (dojo.js, bootstrap.js, hostenv_*.js, loader.js) into four
> modules:
>  * dojo bootstrap
>  * browser sniffing
>  * DOMContentLoaded detection/processing
>  * unload detection/processing
> Smaller things like console guarantee are bracketed by has.js; e.g.
> if(!has("dojo-guarantee-console")){
>  //etc.
> }
> My overarching design goal here is to refactor orthogonal features into
> independent modules.
> has.js:
> I'm using has.js throughout the new bootstrap, and there are lots of design
> points to debate with has.js--I've had several with myself :) That said,
> here's my current plan.
> The module dojo/has will implement has, that is, the function has and its
> methods, *not* the feature tests. The implementation is taken from the
> has.js
> project with the exception of the obvious things like the lengthy DOM test
> that is not needed for a browser-only application. I'll also provide an
> alternate module that simply aliases a preexisting global has.
> The has.js feature tests are copied into a directory and made AMD loadable.
> (Basically what Kris has already done, but, unconditionally AMD modules).
> An additional feature test module is included, namely "dojo", for things
> like
> "dojo-guarantee-console".
> The *source version* unconditionally loads many of the has feature test
> modules (I haven't figured out which ones yet). This makes it easy to write
> code using has.js...the feature test is already loaded.
> Built version of dojo and/or apps will...
>  * discard all unused has feature tests
>  * aggregate all feature tests into a single module
>  * discard all build-time-known has applications and fold code accordingly
>  * (optionally) rename the lengthy has feature names to use integers
> The key benefits of this design:
>  * minimizes complexity writing code (the test is already there; just use
> it)
>  * minimizes size for release code (no unused tests are included)
> Back compat to sync mode:
> We need to support dojo.provide/require for the 1.x line. *Please* correct
> me
> if I'm wrong, dropping this support would make things better.
> Therefore, optionally but by default, dojo boot will include a new impl of
> dojo.provide/require that will slip the loader into and out of sync mode
> and
> be 100% compatible with the current impl of these functions. In short, 1.6
> simulated AMD; 1.7 will simulate dojo.provide/require.
> You can see there are lots of moving parts. I've done this a couple of
> times
> before (sans has.js) with my dojo-sie project, so I think it can be done.
> Best,
> Rawld
> On Friday 11 March 2011 07:10:06 Kris Zyp wrote:
> > There are a couple of additional overarching goals that I would like to
> > see pursued in 1.7. First, we should start using the has() pattern for
> > feature detection branching in our code. Here is the ticket for (and
> > explaining) this enhancement:
> > http://bugs.dojotoolkit.org/ticket/12431
> >
> > Second, as our AMD support will be improved in 1.7, we should start
> > using more precise dependency lists to facilitate highly optimized
> > builds (only what is needed) and fewer runtime property lookups:
> > http://bugs.dojotoolkit.org/ticket/12432
> >
> > I don't think the entirety of the Dojo codebase necessarily needs to be
> > upgraded to these two coding improvements, but we should try to perform
> > these upgrades when possible on code that is actively maintained or
> > developed, or heavily used modules.
> >
> > Also, if anyone is interested here is patch for adding a module for
> > supporting native JSON parsing (using the techniques listed above):
> > http://bugs.dojotoolkit.org/ticket/8111
> > <http://bugs.dojotoolkit.org/ticket/8111#comment:22>
> >
> > Thanks,
> > Kris
> _______________________________________________
> 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/20110315/e91df019/attachment.htm 

More information about the dojo-contributors mailing list