[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
http://thread.gmane.org/gmane.comp.web.dojo.devel/13600/focus=13788),
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