As discussed during the weekly meeting today, we, as a community, would like
to start getting DojoX projects converted over to the AMD module format as has
been done in dojo and dijit. It would be great if DojoX project owners could
accomplish this task for their projects in the near future. This message
describes the process.

Background:

The module format used in dojo and dijit has been converted to be compliant
with the commonJS asynchronous module definition (AMD) specification
(http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition). This work is
in preparation for including asynchronous, AMD-compliant loaders and loading
in the near future--we're currently shooting to have this in as a preview
(minimally supported) by 1.7.

It is important to understand that there has been no substantive feature or
behavior change to the toolkit vis-a-vis the new module format so far:

* The v1.5 synchronous loader has been modified to consume the AMD module
format just as if the old format was being used. (See the last 80 lines of
dojo/_base/_loader/loader.js).

* The v1.5 build system has been modified to transpose the modules back to
the v1.5 format as a preprocessing step; the build then proceeds just as if
the modules were never changed. (See transformAsyncModule in
util/buildscripts/jslib/fileutil.js).

Process:

The change pattern is very simple. The hypothetical module my.module:

dojo.provide("my.module");
dojo.require("some.module.a");
<module contents>

Is rewritten as:

define("my/module", ["dojo", "some/module/a"], function(dojo) {
<module contents>
return my.module;
});


Key Points:

1. Module names are converted by replacing dots with slashes.
2. The module given by dojo.provide becomes the first argument to define.
3. If you were depending on dojo.provide to construct an object for you,
then you'll need to write dojo.getObject("module", true, "my"). This ensures
my.module exists, but does not step on it if it already exists upon entry. See
dojo.back for an example.
4. The dependency vector (the second argument to define) and the lambda list
for the factory function should start with "dojo" and dojo; this gives your
module access to the global dojo object and is demonstrated above.
4. If your module uses dijit and/or dojox, include them as well. See
dijit/MenuBar for an example.
5. The set of dojo.requires becomes the remaining contents of the dependency
vector.
6. define(<moduleId>, <dependencies>, function(<params>) { must all be on
the same line.

Watch Out:

Yes, it's true...

define(<moduleId>, <dependencies>, function(<params>) {

must all be on the same line. This makes the build transform easy and we don't
want to invest a lost in making the current build system consume the new
module format (new build systems coming too!).

Make sure to test and then run a build on your conversion to get some
confidence it was done correctly.

There will be a few more things to pay attention to in order to get your
project to load with an async loader, but I'll cover that in another article.

Get Excited:

Asynchronous loading makes dev much nicer. I have seen 10x improvement in load
times. You can monitor James Burke's requirejs (http://requirejs.org/) or my
dojo-sie (http://dojo-sie.altoviso.com) to see how this work is evolving.

Best,
Rawld

Search Discussions

  • Kris Zyp at Nov 4, 2010 at 9:42 am
    Rawld,
    Do you have a tool for auto-conversion of modules, at least for the
    dojo.provide/require to define() conversion? Could we create a converted
    copy of DojoX that maintainers could grab their package and perform the
    remaining conversion and testing needed to get it ready, if they want to?
    Kris
    On 11/4/2010 4:21 AM, Rawld Gill wrote:
    As discussed during the weekly meeting today, we, as a community, would like
    to start getting DojoX projects converted over to the AMD module format as has
    been done in dojo and dijit. It would be great if DojoX project owners could
    accomplish this task for their projects in the near future. This message
    describes the process.

    Background:

    The module format used in dojo and dijit has been converted to be compliant
    with the commonJS asynchronous module definition (AMD) specification
    (http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition). This work is
    in preparation for including asynchronous, AMD-compliant loaders and loading
    in the near future--we're currently shooting to have this in as a preview
    (minimally supported) by 1.7.

    It is important to understand that there has been no substantive feature or
    behavior change to the toolkit vis-a-vis the new module format so far:

    * The v1.5 synchronous loader has been modified to consume the AMD module
    format just as if the old format was being used. (See the last 80 lines of
    dojo/_base/_loader/loader.js).

    * The v1.5 build system has been modified to transpose the modules back to
    the v1.5 format as a preprocessing step; the build then proceeds just as if
    the modules were never changed. (See transformAsyncModule in
    util/buildscripts/jslib/fileutil.js).

    Process:

    The change pattern is very simple. The hypothetical module my.module:

    dojo.provide("my.module");
    dojo.require("some.module.a");
    <module contents>

    Is rewritten as:

    define("my/module", ["dojo", "some/module/a"], function(dojo) {
    <module contents>
    return my.module;
    });


    Key Points:

    1. Module names are converted by replacing dots with slashes.
    2. The module given by dojo.provide becomes the first argument to define.
    3. If you were depending on dojo.provide to construct an object for you,
    then you'll need to write dojo.getObject("module", true, "my"). This ensures
    my.module exists, but does not step on it if it already exists upon entry. See
    dojo.back for an example.
    4. The dependency vector (the second argument to define) and the lambda list
    for the factory function should start with "dojo" and dojo; this gives your
    module access to the global dojo object and is demonstrated above.
    4. If your module uses dijit and/or dojox, include them as well. See
    dijit/MenuBar for an example.
    5. The set of dojo.requires becomes the remaining contents of the dependency
    vector.
    6. define(<moduleId>, <dependencies>, function(<params>) { must all be on
    the same line.

    Watch Out:

    Yes, it's true...

    define(<moduleId>, <dependencies>, function(<params>) {

    must all be on the same line. This makes the build transform easy and we don't
    want to invest a lost in making the current build system consume the new
    module format (new build systems coming too!).

    Make sure to test and then run a build on your conversion to get some
    confidence it was done correctly.

    There will be a few more things to pay attention to in order to get your
    project to load with an async loader, but I'll cover that in another article.

    Get Excited:

    Asynchronous loading makes dev much nicer. I have seen 10x improvement in load
    times. You can monitor James Burke's requirejs (http://requirejs.org/) or my
    dojo-sie (http://dojo-sie.altoviso.com) to see how this work is evolving.

    Best,
    Rawld
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Ben Hockey at Nov 4, 2010 at 10:35 am
    inline
    On Thu, Nov 4, 2010 at 9:42 AM, Kris Zyp wrote:

    Rawld,
    Do you have a tool for auto-conversion of modules, at least for the
    dojo.provide/require to define() conversion? Could we create a converted
    copy of DojoX that maintainers could grab their package and perform the
    remaining conversion and testing needed to get it ready, if they want to?
    Kris
    agreed... a script would help with a large portion of the work. i started
    converting dojox.math.* and was working on dojox.encoding.* and it seems
    i've already broken the rules. my define statements are not on a single
    line - i'll have to revisit that code. i was also aiming to slightly
    refactor the modules to try and reduce dependencies on dojo base where
    possible so that the modules could be consumed by a wider audience.

    On 11/4/2010 4:21 AM, Rawld Gill wrote:
    As discussed during the weekly meeting today, we, as a community, would
    like
    as an aside, the transcripts of the meeting have stopped being generated.
    can we bump dojogurl to wake her up?

    to start getting DojoX projects converted over to the AMD module format as has
    been done in dojo and dijit. It would be great if DojoX project owners could
    accomplish this task for their projects in the near future. This message
    describes the process.
    i don't own any dojox projects but if anyone wants help, ping me - i *may*
    have some time to help. i had already contacted eugene about converting
    dojox.encoding and it's dependency, dojox.math. i started to do some work
    on that but it seems that the build tool is probably not as smart as i had
    hoped so i'll need to revisit some of that to put my define statements on a
    single line.

    Background:

    The module format used in dojo and dijit has been converted to be compliant
    with the commonJS asynchronous module definition (AMD) specification
    (http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition). This work is
    in preparation for including asynchronous, AMD-compliant loaders and loading
    in the near future--we're currently shooting to have this in as a preview
    (minimally supported) by 1.7.

    It is important to understand that there has been no substantive feature or
    behavior change to the toolkit vis-a-vis the new module format so far:

    * The v1.5 synchronous loader has been modified to consume the AMD module
    format just as if the old format was being used. (See the last 80 lines of
    dojo/_base/_loader/loader.js).

    * The v1.5 build system has been modified to transpose the modules back to
    the v1.5 format as a preprocessing step; the build then proceeds just as if
    the modules were never changed. (See transformAsyncModule in
    util/buildscripts/jslib/fileutil.js).

    Process:

    The change pattern is very simple. The hypothetical module my.module:

    dojo.provide("my.module");
    dojo.require("some.module.a");
    <module contents>

    Is rewritten as:

    define("my/module", ["dojo", "some/module/a"], function(dojo) {
    <module contents>
    return my.module;
    });


    Key Points:

    1. Module names are converted by replacing dots with slashes.
    2. The module given by dojo.provide becomes the first argument to
    define.
    is this needed? can we just define module anonymously?

    3. If you were depending on dojo.provide to construct an object for you,
    then you'll need to write dojo.getObject("module", true, "my"). This ensures
    my.module exists, but does not step on it if it already exists upon
    entry. See
    dojo.back for an example.
    4. The dependency vector (the second argument to define) and the lambda list
    for the factory function should start with "dojo" and dojo; this gives your
    module access to the global dojo object and is demonstrated above.
    4. If your module uses dijit and/or dojox, include them as well. See
    dijit/MenuBar for an example.
    5. The set of dojo.requires becomes the remaining contents of the
    dependency
    vector.
    6. define(<moduleId>, <dependencies>, function(<params>) { must all be on
    the same line.

    Watch Out:

    Yes, it's true...

    define(<moduleId>, <dependencies>, function(<params>) {

    must all be on the same line. This makes the build transform easy and we don't
    want to invest a lost in making the current build system consume the new
    module format (new build systems coming too!).
    Make sure to test and then run a build on your conversion to get some
    confidence it was done correctly.

    There will be a few more things to pay attention to in order to get your
    project to load with an async loader, but I'll cover that in another
    article.

    Get Excited:

    Asynchronous loading makes dev much nicer. I have seen 10x improvement in load
    times. You can monitor James Burke's requirejs (http://requirejs.org/) or my
    dojo-sie (http://dojo-sie.altoviso.com) to see how this work is evolving.
    Best,
    Rawld
    _______________________________________________
    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/20101104/b1222132/attachment-0001.htm
  • Kris Zyp at Nov 4, 2010 at 10:47 am

    On 11/4/2010 8:35 AM, Ben Hockey wrote:
    Key Points:

    1. Module names are converted by replacing dots with slashes.
    2. The module given by dojo.provide becomes the first argument
    to define.


    is this needed? can we just define module anonymously?
    Yes, good point, the current sync loader should now support anonymous
    modules, and I would definitely encourage DojoX modules to be anonymous.
    Dojo and Dijit are not anonymous because we want to be able to use them
    in hand-writted script tags, but for DojoX, I think portability is much
    more important.
    Thanks,
    Kris
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101104/a2e9cdb5/attachment.htm
  • Ben Hockey at Nov 4, 2010 at 11:31 am
    is it too much of a stretch to not expose modules via the dojox "global"? i
    suspect that there would be some backlash over doing this so that would be
    the down side. however, after converting a few of these modules, the only
    reason some of them have a dependency on dojo now is so that they can call
    dojo.getObject to attach to dojox somehow. i've already taken rawld's
    advice and i'm excited about AMD so i'm likely to try to move everything too
    quickly - any sage advice about losing the globals for dojox?

    to clarify, i mean no longer having dojox.math.BigInteger as a global. if
    you want to use BigInteger you can only get it by defining it as a
    dependency.

    define(["dojox/math/BigInteger"], function (BigInteger) {
    // do stuff with BigInteger - dojox.math.BigInteger doesn't exist
    });

    my hope is to make every thing as portable as possible - anonymous
    definitions and nothing is exposed via a global handle. my concern is that
    this is not backwards compatible but i was wondering if we have the liberty
    to do this with dojox.

    thanks,

    ben...

    On Thu, Nov 4, 2010 at 10:47 AM, Kris Zyp wrote:



    On 11/4/2010 8:35 AM, Ben Hockey wrote:

    Key Points:

    1. Module names are converted by replacing dots with slashes.
    2. The module given by dojo.provide becomes the first argument to
    define.
    is this needed? can we just define module anonymously?


    Yes, good point, the current sync loader should now support anonymous
    modules, and I would definitely encourage DojoX modules to be anonymous.
    Dojo and Dijit are not anonymous because we want to be able to use them in
    hand-writted script tags, but for DojoX, I think portability is much more
    important.
    Thanks,
    Kris
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101104/14c210af/attachment.htm
  • Kris Zyp at Nov 4, 2010 at 11:36 am
    Yes, it is good form to avoid dependence on the "dojox"
    pseudo-module/global thing if possible. I believe the sync loader should
    create the global and async loaders shouldn't. For example,
    dojox.math.BigInteger should be written:

    define([], function(){
    // Bits per digit
    var dbits;
    ...
    return BigInteger;
    });

    And dojox.data.JsonRestStore should be written:

    define(["./ServiceStore", "../rpc/JsonRest"], function(ServiceStore,
    JsonRest){
    return dojo.declare(ServiceStore,
    {
    constructor: function(options){
    ....

    So dojo.require("dojox.math.BigInteger") should make dojox.math.BigInteger available, but require(["dojox/math/BigInteger"]) should not.
    Kris

    On 11/4/2010 9:31 AM, Ben Hockey wrote:
    is it too much of a stretch to not expose modules via the dojox
    "global"? i suspect that there would be some backlash over doing this
    so that would be the down side. however, after converting a few of
    these modules, the only reason some of them have a dependency on dojo
    now is so that they can call dojo.getObject to attach to dojox
    somehow. i've already taken rawld's advice and i'm excited about AMD
    so i'm likely to try to move everything too quickly - any sage advice
    about losing the globals for dojox?

    to clarify, i mean no longer having dojox.math.BigInteger as a global.
    if you want to use BigInteger you can only get it by defining it as a
    dependency.

    define(["dojox/math/BigInteger"], function (BigInteger) {
    // do stuff with BigInteger - dojox.math.BigInteger doesn't exist
    });

    my hope is to make every thing as portable as possible - anonymous
    definitions and nothing is exposed via a global handle. my concern is
    that this is not backwards compatible but i was wondering if we have
    the liberty to do this with dojox.

    thanks,

    ben...


    On Thu, Nov 4, 2010 at 10:47 AM, Kris Zyp <kzyp at dojotoolkit.org
    wrote:


    On 11/4/2010 8:35 AM, Ben Hockey wrote:


    Key Points:

    1. Module names are converted by replacing dots with slashes.
    2. The module given by dojo.provide becomes the first
    argument to define.


    is this needed? can we just define module anonymously?
    Yes, good point, the current sync loader should now support
    anonymous modules, and I would definitely encourage DojoX modules
    to be anonymous. Dojo and Dijit are not anonymous because we want
    to be able to use them in hand-writted script tags, but for DojoX,
    I think portability is much more important.
    Thanks,
    Kris
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101104/7f636ecc/attachment.htm
  • Ben Hockey at Nov 4, 2010 at 12:16 pm
    it seems that the fileUtil.transformAsyncModule used by the build tool may
    not be ready for anonymous modules. is it a quickfix? i opened a ticket
    for it http://trac.dojotoolkit.org/ticket/11919

    ben...
    On Thu, Nov 4, 2010 at 11:36 AM, Kris Zyp wrote:

    Yes, it is good form to avoid dependence on the "dojox"
    pseudo-module/global thing if possible. I believe the sync loader should
    create the global and async loaders shouldn't. For example,
    dojox.math.BigInteger should be written:

    define([], function(){
    // Bits per digit
    var dbits;
    ...
    return BigInteger;
    });

    And dojox.data.JsonRestStore should be written:

    define(["./ServiceStore", "../rpc/JsonRest"], function(ServiceStore,
    JsonRest){
    return dojo.declare(ServiceStore,
    {
    constructor: function(options){
    ....

    So dojo.require("dojox.math.BigInteger") should make dojox.math.BigInteger available, but require(["dojox/math/BigInteger"]) should not.
    Kris


    On 11/4/2010 9:31 AM, Ben Hockey wrote:

    is it too much of a stretch to not expose modules via the dojox "global"?
    i suspect that there would be some backlash over doing this so that would
    be the down side. however, after converting a few of these modules, the
    only reason some of them have a dependency on dojo now is so that they can
    call dojo.getObject to attach to dojox somehow. i've already taken rawld's
    advice and i'm excited about AMD so i'm likely to try to move everything too
    quickly - any sage advice about losing the globals for dojox?

    to clarify, i mean no longer having dojox.math.BigInteger as a global.
    if you want to use BigInteger you can only get it by defining it as a
    dependency.

    define(["dojox/math/BigInteger"], function (BigInteger) {
    // do stuff with BigInteger - dojox.math.BigInteger doesn't exist
    });

    my hope is to make every thing as portable as possible - anonymous
    definitions and nothing is exposed via a global handle. my concern is that
    this is not backwards compatible but i was wondering if we have the liberty
    to do this with dojox.

    thanks,

    ben...

    On Thu, Nov 4, 2010 at 10:47 AM, Kris Zyp wrote:



    On 11/4/2010 8:35 AM, Ben Hockey wrote:

    Key Points:

    1. Module names are converted by replacing dots with slashes.
    2. The module given by dojo.provide becomes the first argument to
    define.
    is this needed? can we just define module anonymously?


    Yes, good point, the current sync loader should now support anonymous
    modules, and I would definitely encourage DojoX modules to be anonymous.
    Dojo and Dijit are not anonymous because we want to be able to use them in
    hand-writted script tags, but for DojoX, I think portability is much more
    important.
    Thanks,
    Kris
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101104/86e971e1/attachment.htm
  • Bill Keese at Nov 5, 2010 at 5:42 am
    So dojo.require("dojox.math.BigInteger") should make
    dojox.math.BigInteger available, but require(["dojox/math/BigInteger"])
    should not.

    That's a clever idea.

    I worry because there's not always a 1-1 mapping between modules (aka
    files) and constructors/namespaces, for example
    http://bugs.dojotoolkit.org/browser/dojox/trunk/editor/plugins/TablePlugins.js
    and http://bugs.dojotoolkit.org/browser/dojox/trunk/grid/cells/dijit.js.

    Obviously going forward we want to always have a 1-1 mapping. Maybe we
    can just fix the errant files.

    On 11/5/10 12:36 AM, Kris Zyp wrote:
    Yes, it is good form to avoid dependence on the "dojox"
    pseudo-module/global thing if possible. I believe the sync loader
    should create the global and async loaders shouldn't. For example,
    dojox.math.BigInteger should be written:
    define([], function(){
    // Bits per digit
    var dbits;
    ...
    return BigInteger;
    });

    And dojox.data.JsonRestStore should be written:

    define(["./ServiceStore", "../rpc/JsonRest"], function(ServiceStore,
    JsonRest){
    return dojo.declare(ServiceStore,
    {
    constructor: function(options){
    ....

    So dojo.require("dojox.math.BigInteger") should make dojox.math.BigInteger available, but require(["dojox/math/BigInteger"]) should not.
    Kris
    On 11/4/2010 9:31 AM, Ben Hockey wrote:
    is it too much of a stretch to not expose modules via the dojox
    "global"? i suspect that there would be some backlash over doing
    this so that would be the down side. however, after converting a few
    of these modules, the only reason some of them have a dependency on
    dojo now is so that they can call dojo.getObject to attach to dojox
    somehow. i've already taken rawld's advice and i'm excited about AMD
    so i'm likely to try to move everything too quickly - any sage advice
    about losing the globals for dojox?

    to clarify, i mean no longer having dojox.math.BigInteger as a
    global. if you want to use BigInteger you can only get it by
    defining it as a dependency.

    define(["dojox/math/BigInteger"], function (BigInteger) {
    // do stuff with BigInteger - dojox.math.BigInteger doesn't exist
    });

    my hope is to make every thing as portable as possible - anonymous
    definitions and nothing is exposed via a global handle. my concern
    is that this is not backwards compatible but i was wondering if we
    have the liberty to do this with dojox.

    thanks,

    ben...


    On Thu, Nov 4, 2010 at 10:47 AM, Kris Zyp <kzyp at dojotoolkit.org
    wrote:


    On 11/4/2010 8:35 AM, Ben Hockey wrote:


    Key Points:

    1. Module names are converted by replacing dots with slashes.
    2. The module given by dojo.provide becomes the first
    argument to define.


    is this needed? can we just define module anonymously?
    Yes, good point, the current sync loader should now support
    anonymous modules, and I would definitely encourage DojoX modules
    to be anonymous. Dojo and Dijit are not anonymous because we want
    to be able to use them in hand-writted script tags, but for
    DojoX, I think portability is much more important.
    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/20101105/dfe77ba0/attachment-0001.htm
  • Kris Zyp at Nov 5, 2010 at 2:28 pm

    On 11/5/2010 3:42 AM, Bill Keese wrote:
    So dojo.require("dojox.math.BigInteger") should make
    dojox.math.BigInteger available, but
    require(["dojox/math/BigInteger"]) should not.

    That's a clever idea.

    I worry because there's not always a 1-1 mapping between modules (aka
    files) and constructors/namespaces, for example
    http://bugs.dojotoolkit.org/browser/dojox/trunk/editor/plugins/TablePlugins.js
    and http://bugs.dojotoolkit.org/browser/dojox/trunk/grid/cells/dijit.js.

    Obviously going forward we want to always have a 1-1 mapping. Maybe
    we can just fix the errant files.
    Note that
    dojo.declare("dojox.editor.plugins._TableHandler", dijit._editor._Plugin,{
    is going to create a the global dojox.editor.plugins._TableHandler
    regardless of how the module is required. Modules only need to be
    switched to 1-1 if they do the full conversion to anonymous modules and
    anonymous class declaration.
    Kris
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101105/9cd30c04/attachment.htm
  • Ben Hockey at Nov 4, 2010 at 2:05 pm
    in addition to all being on the same line, it must be the first line and
    there must not be any leading spaces (including blank lines) or comments

    ben...

    6. define(<moduleId>, <dependencies>, function(<params>) { must all be on
    the same line.

    Watch Out:

    Yes, it's true...

    define(<moduleId>, <dependencies>, function(<params>) {

    must all be on the same line. This makes the build transform easy and we
    don't
    want to invest a lost in making the current build system consume the new
    module format (new build systems coming too!).
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101104/617e2c34/attachment.htm
  • Shane O'Sullivan at Nov 4, 2010 at 2:13 pm
    Wow, that's pretty specific, makes me feel like I'm back writing COBOL
    where every line had to be preceded by 7 spaces :-)

    Can't the tool just trim comments and whitespace before looking for
    the define pattern? This seems very brittle otherwise, especially for
    our users, but I can also see us Dojo devs getting it wrong pretty
    frequently

    Shane

    2010/11/4 Ben Hockey <neonstalwart at gmail.com>:
    in addition to all being on the same line, it must be the first line and
    there must not be any leading spaces (including blank lines) or comments
    ben...
    ?6. define(<moduleId>, <dependencies>, function(<params>) { must all be on
    the same line.

    Watch Out:

    Yes, it's true...

    define(<moduleId>, <dependencies>, function(<params>) {

    must all be on the same line. This makes the build transform easy and we
    don't
    want to invest a lost in making the current build system consume the new
    module format (new build systems coming too!).

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Rawld Gill at Nov 5, 2010 at 3:37 am

    On Thursday 04 November 2010 11:13:34 Shane O'Sullivan wrote:
    Wow, that's pretty specific, makes me feel like I'm back writing COBOL
    where every line had to be preceded by 7 spaces :-)

    Can't the tool just trim comments and whitespace before looking for
    the define pattern? This seems very brittle otherwise, especially for
    our users, but I can also see us Dojo devs getting it wrong pretty
    frequently
    Probably beating a dead horse here...but this work it not intended for our
    users.

    Best,
    Rawld
  • Rawld Gill at Nov 4, 2010 at 4:57 pm
    I'm away from the office most of today, but I've read all the traffic on the
    thread about

    * automatic conversion
    * brittleness of build

    and I'll hang some immediate feedback here.


    Automatic Conversion:

    I have a lisp program to do this. I'll pull the entire dojoX tree, run it, and
    post the results to get people started.


    Brittleness of Build:

    Yes, it is brittle. Regexs are always brittle when you really need a parser
    [rant deleted] and the build mod makes ZERO effort to be smart. It is *not*
    intended to be used for very long or by very many. I don't have the cycles and
    think it a poor choice of resources to try to make the old build system work
    well with AMD so I do not pretend to do so. Fwiw, I will have a new build
    system [with a parser] available soon.

    That said, I'll write a *slightly* smarter regex transform tonight and post it
    to this thread.


    Anonymous Modules:

    I'm fine with writing anonymous modules (i.e., no explicit moduleId given).
    The only problem remains the v1.x build system. I'll put in a *naive* method
    to accomplish this and post instructions tonight.


    Caution:

    We must be careful about the slippery slope of trying to make v1.x immediately
    swallow AMD and async loader. In 95% of the cases the work is trivial. In 5%,
    it's aggravating (for example, timing issues with IE graphics systems, weird
    global variable manipulations). I've built some experience at all of this and
    will post info the moment I have dojo-sie back up (it's about 2/3's of the way
    through a major refactor to make it fully compliant/use AMD, has.js, dojo 2.0
    base/Pulsar).

    Hope this helps!

    Best,
    Rawld
  • Rawld Gill at Nov 6, 2010 at 8:02 pm

    On Thursday 04 November 2010 13:57:36 Rawld Gill wrote:
    Anonymous Modules:

    I'm fine with writing anonymous modules (i.e., no explicit moduleId given).
    The only problem remains the v1.x build system.
    This is now fixed; see http://trac.dojotoolkit.org/ticket/11919#comment:9.

    Best,
    Rawld
  • Rawld Gill at Nov 6, 2010 at 9:00 pm

    On Thursday 04 November 2010 13:57:36 Rawld Gill wrote:
    Automatic Conversion:

    I have a lisp program to do this. I'll pull the entire dojoX tree, run it,
    and post the results to get people started.
    I converted the entire dojox tree as of v23125. You can get the converted tree
    from http://rcgill.dojotoolkit.org/dojox-AMD.tar.gz.

    Notes:

    * Any module with a dojo.provide and all i18n bundles were converted.

    * All modules were converted as anonymous AMD modules with an AMD-ID pragma
    for the build system (see http://trac.dojotoolkit.org/ticket/11919#comment:9
    for details).

    * The conversion returns an object of the same name as the module (e.g., the
    module dojox/my/project will return dojox.my.project). This is probably not
    what you want, so you'll have to modify accordingly.

    * It's only a start. It helped me a lot when I converted dojo and dijit, but
    you'll need to look at your modules and think about the dependency list, the
    effect of not having a dojo.provide create an object for you, and the factory
    return.

    Good Luck!

    Best,
    Rawld
  • Sasha Firsov at Nov 8, 2010 at 11:29 am
    Just curious question.
    Can we convert in similar way the global scope functions from JS to make
    the package out of content?

    That will allow to prevent JSON-ing and packaging and use anonynous
    functions during development of independent module and have insulated
    scope for compiled version (if ever there is a need for one).

    You could not imagine how difficult is to train newbies and let them
    into debugger on dojo...
    Even for experienced people quite often anonymous functions on hashmaps
    are evil to troubleshoot in certain environments.
    Eventually shall be an option in compiler to unwrap anonymous members to
    global scope - for performance and debugging reasons.
    Sasha

    On 11/6/2010 6:00 PM, Rawld Gill wrote:
    On Thursday 04 November 2010 13:57:36 Rawld Gill wrote:
    Automatic Conversion:

    I have a lisp program to do this. I'll pull the entire dojoX tree, run it,
    and post the results to get people started.
    I converted the entire dojox tree as of v23125. You can get the converted tree
    from http://rcgill.dojotoolkit.org/dojox-AMD.tar.gz.

    Notes:

    * Any module with a dojo.provide and all i18n bundles were converted.

    * All modules were converted as anonymous AMD modules with an AMD-ID pragma
    for the build system (see http://trac.dojotoolkit.org/ticket/11919#comment:9
    for details).

    * The conversion returns an object of the same name as the module (e.g., the
    module dojox/my/project will return dojox.my.project). This is probably not
    what you want, so you'll have to modify accordingly.

    * It's only a start. It helped me a lot when I converted dojo and dijit, but
    you'll need to look at your modules and think about the dependency list, the
    effect of not having a dojo.provide create an object for you, and the factory
    return.

    Good Luck!

    Best,
    Rawld

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Adam L. Peller at Nov 5, 2010 at 11:56 am
    Hi Rawld.

    Thanks again for tackling this important issue, particularly as it
    relates to i18n bundles, and sorry I have fallen behind in tracking
    the latest changes. The other day I went to update the dojo.cldr
    resources and realized they had been directly transcoded. These are
    generated resources, so I will need to do this from script. A few
    questions from things I noticed. The i18n bundles do not seem to
    exactly match what James has specified for require JS:

    1) The i18n! prefix is used in the resources. My understanding is
    that i18n! is only meant used where referencing an i18n resource from
    code, where the resource itself should be written as 'anonymous' or
    without a module identifier
    2) The contents are surrounded with comments like //begin v1.x content

    both conventions appear to be referenced in fileUtil.js, so I'm
    wondering if there's some magic going on which depends on either of
    these, or whether it's ok to go directly to the format as described at
    requirejs.org

    I imagine these issues will come up for dojox modules with nls bundles as well.

    Regards,
    Adam

    On Thu, Nov 4, 2010 at 6:21 AM, Rawld Gill wrote:
    As discussed during the weekly meeting today, we, as a community, would like
    to start getting DojoX projects converted over to the AMD module format as has
    been done in dojo and dijit. ?It would be great if DojoX project owners could
    accomplish this task for their projects in the near future. This message
    describes the process.

    Background:

    The module format used in dojo and dijit has been converted to be compliant
    with the commonJS asynchronous module definition (AMD) specification
    (http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition). This work is
    in preparation for including asynchronous, AMD-compliant loaders and loading
    in the near future--we're currently shooting to have this in as a preview
    (minimally supported) by 1.7.

    It is important to understand that there has been no substantive feature or
    behavior change to the toolkit vis-a-vis the new module format so far:

    ?* The v1.5 synchronous loader has been modified to consume the AMD module
    format just as if the old format was being used. (See the last 80 lines of
    dojo/_base/_loader/loader.js).

    ?* The v1.5 build system has been modified to transpose the modules back to
    the v1.5 format as a preprocessing step; the build then proceeds just as if
    the modules were never changed. (See transformAsyncModule in
    util/buildscripts/jslib/fileutil.js).

    Process:

    The change pattern is very simple. The hypothetical module my.module:

    dojo.provide("my.module");
    dojo.require("some.module.a");
    <module contents>

    Is rewritten as:

    define("my/module", ["dojo", "some/module/a"], function(dojo) {
    <module contents>
    return my.module;
    });


    Key Points:

    ?1. Module names are converted by replacing dots with slashes.
    ?2. The module given by dojo.provide becomes the first argument to define.
    ?3. If you were depending on dojo.provide to construct an object for you,
    then you'll need to write dojo.getObject("module", true, "my"). This ensures
    my.module exists, but does not step on it if it already exists upon entry. See
    dojo.back for an example.
    ?4. The dependency vector (the second argument to define) and the lambda list
    for the factory function should start with "dojo" and dojo; this gives your
    module access to the global dojo object and is demonstrated above.
    ?4. If your module uses dijit and/or dojox, include them as well. See
    dijit/MenuBar for an example.
    ?5. The set of dojo.requires becomes the remaining contents of the dependency
    vector.
    ?6. define(<moduleId>, <dependencies>, function(<params>) { must all be on
    the same line.

    Watch Out:

    Yes, it's true...

    define(<moduleId>, <dependencies>, function(<params>) {

    must all be on the same line. This makes the build transform easy and we don't
    want to invest a lost in making the current build system consume the new
    module format (new build systems coming too!).

    Make sure to test and then run a build on your conversion to get some
    confidence it was done correctly.

    There will be a few more things to pay attention to in order to get your
    project to load with an async loader, but I'll cover that in another article.

    Get Excited:

    Asynchronous loading makes dev much nicer. I have seen 10x improvement in load
    times. You can monitor James Burke's requirejs (http://requirejs.org/) or my
    dojo-sie (http://dojo-sie.altoviso.com) to see how this work is evolving.

    Best,
    Rawld
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Rawld Gill at Nov 7, 2010 at 2:47 pm
    Hi Adam,

    Sorry for the delayed response...just too many items on the list these days!
    On Friday 05 November 2010 08:56:42 Adam L. Peller wrote:
    Hi Rawld.
    The i18n bundles do not seem to
    exactly match what James has specified for require JS:

    1) The i18n! prefix is used in the resources. My understanding is
    that i18n! is only meant used where referencing an i18n resource from
    code, where the resource itself should be written as 'anonymous' or
    without a module identifier
    This is no longer necessary; your understanding is correct.
    2) The contents are surrounded with comments like //begin v1.x content

    both conventions appear to be referenced in fileUtil.js, so I'm
    wondering if there's some magic going on which depends on either of
    these, or whether it's ok to go directly to the format as described at
    requirejs.org
    Failing to use the "begin/end v1.x content" pragma will break the build
    system.

    The idea is to be able to have dojo and dijit (and dojox modules, as owners
    have time to convert) modules expressed in the AMD format *without* changing
    the v1.x loaders and/or build system in any significant way. This makes the
    modules available to early implementers/adopters of AMD loaders/build systems
    so we can start to work out all the issues associated with this new machinery
    before publishing it to the community at large, while being *completely
    invisible* to everybody else.

    We are--at least for the moment--making the decision to not upgrade the v1.x
    build system to handle this new stuff with any real intelligence.
    Translation: the build transforms are a short-term kludge.

    With this in mind, the cheapest way to get the build system to consume the
    i18n bundles in AMD format was to just surround the v1.x portion with the
    lines

    //begin v1.x content

    and

    //end v1.x content

    The first step in the build is to copy all target files to the build tree.
    During this step, I put a process in that simply filters the i18n bundles on
    these pragmas. From that point forward, these resources are identical to v1.x
    bundles, so the build system does fine.

    In working on your scripts to generate localized bundles you need only wrap
    the current output with the prefix:

    define(
    //begin v1.x content

    and the suffix:

    //end v1.x content
    );

    For example, look at dojo/nls/ar/date.js

    For the root bundle the pragmas need to be placed to cut out the root
    property (look at , e.g., dojo/nls/date.js). Of course the scripts will need
    to calculate the root property.

    Let me know if you need more.

    Best,
    Rawld
  • Adam L. Peller at Nov 8, 2010 at 9:48 pm
    Thanks, Rawld!

    So I'm now realizing the tests are failing to load because I'm getting
    'define not found' for dojo/cldr/supplemental.js... Any idea what I
    did wrong?

    -Adam

    On Sun, Nov 7, 2010 at 2:47 PM, Rawld Gill wrote:
    Hi Adam,

    Sorry for the delayed response...just too many items on the list these days!
    On Friday 05 November 2010 08:56:42 Adam L. Peller wrote:
    Hi Rawld.
    ? The i18n bundles do not seem to
    exactly match what James has specified for require JS:

    1) The i18n! prefix is used in the resources. ?My understanding is
    that i18n! is only meant used where referencing an i18n resource from
    code, where the resource itself should be written as 'anonymous' or
    without a module identifier
    This is no longer necessary; your understanding is correct.
    2) The contents are surrounded with comments like //begin v1.x content

    both conventions appear to be referenced in fileUtil.js, so I'm
    wondering if there's some magic going on which depends on either of
    these, or whether it's ok to go directly to the format as described at
    requirejs.org
    Failing to use the "begin/end v1.x content" pragma will break the build
    system.

    The idea is to be able to have dojo and dijit (and dojox modules, as owners
    have time to convert) modules expressed in the AMD format *without* changing
    the v1.x loaders and/or build system in any significant way. This makes the
    modules available to early implementers/adopters of AMD loaders/build systems
    so we can start to work out all the issues associated with this new machinery
    before publishing it to the community at large, while being ?*completely
    invisible* to everybody else.

    We are--at least for the moment--making the decision to not upgrade the v1.x
    build system to handle this new stuff with any real intelligence.
    Translation: the build transforms are a short-term kludge.

    With this in mind, the cheapest way to get the build system to consume the
    i18n bundles in AMD format was to just surround the v1.x portion with the
    lines

    //begin v1.x content

    and

    //end v1.x content

    The first step in the build is to copy all target files to the build tree.
    During this step, I put a process in that simply filters the i18n bundles on
    these pragmas. From that point forward, these resources are identical to v1.x
    bundles, so the build system does fine.

    In working on your scripts to generate localized bundles you need only wrap
    the current output with the prefix:

    define(
    //begin v1.x content

    and the suffix:

    //end v1.x content
    );

    For example, look at dojo/nls/ar/date.js

    For the root bundle the ?pragmas need to be placed to cut out the root
    property (look at , e.g., dojo/nls/date.js). Of course the scripts will need
    to calculate the root property.

    Let me know if you need more.

    Best,
    Rawld

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Adam L. Peller at Nov 8, 2010 at 9:56 pm
    oops. nevermind, it works for me now... sorry for the noise. But do
    let me know if anyone has trouble with the new i18n bundles.
    On Mon, Nov 8, 2010 at 9:48 PM, Adam L. Peller wrote:
    Thanks, Rawld!

    So I'm now realizing the tests are failing to load because I'm getting
    'define not found' for dojo/cldr/supplemental.js... Any idea what I
    did wrong?

    -Adam

    On Sun, Nov 7, 2010 at 2:47 PM, Rawld Gill wrote:
    Hi Adam,

    Sorry for the delayed response...just too many items on the list these days!
    On Friday 05 November 2010 08:56:42 Adam L. Peller wrote:
    Hi Rawld.
    ? The i18n bundles do not seem to
    exactly match what James has specified for require JS:

    1) The i18n! prefix is used in the resources. ?My understanding is
    that i18n! is only meant used where referencing an i18n resource from
    code, where the resource itself should be written as 'anonymous' or
    without a module identifier
    This is no longer necessary; your understanding is correct.
    2) The contents are surrounded with comments like //begin v1.x content

    both conventions appear to be referenced in fileUtil.js, so I'm
    wondering if there's some magic going on which depends on either of
    these, or whether it's ok to go directly to the format as described at
    requirejs.org
    Failing to use the "begin/end v1.x content" pragma will break the build
    system.

    The idea is to be able to have dojo and dijit (and dojox modules, as owners
    have time to convert) modules expressed in the AMD format *without* changing
    the v1.x loaders and/or build system in any significant way. This makes the
    modules available to early implementers/adopters of AMD loaders/build systems
    so we can start to work out all the issues associated with this new machinery
    before publishing it to the community at large, while being ?*completely
    invisible* to everybody else.

    We are--at least for the moment--making the decision to not upgrade the v1.x
    build system to handle this new stuff with any real intelligence.
    Translation: the build transforms are a short-term kludge.

    With this in mind, the cheapest way to get the build system to consume the
    i18n bundles in AMD format was to just surround the v1.x portion with the
    lines

    //begin v1.x content

    and

    //end v1.x content

    The first step in the build is to copy all target files to the build tree.
    During this step, I put a process in that simply filters the i18n bundles on
    these pragmas. From that point forward, these resources are identical to v1.x
    bundles, so the build system does fine.

    In working on your scripts to generate localized bundles you need only wrap
    the current output with the prefix:

    define(
    //begin v1.x content

    and the suffix:

    //end v1.x content
    );

    For example, look at dojo/nls/ar/date.js

    For the root bundle the ?pragmas need to be placed to cut out the root
    property (look at , e.g., dojo/nls/date.js). Of course the scripts will need
    to calculate the root property.

    Let me know if you need more.

    Best,
    Rawld

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Rawld Gill at Nov 9, 2010 at 2:42 pm

    On Monday 08 November 2010 18:56:47 Adam L. Peller wrote:
    oops. nevermind, it works for me now... sorry for the noise.
    Great! Thanks for helping out here!

    Best,
    Rawld

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedNov 4, '10 at 6:21a
activeNov 9, '10 at 2:42p
posts21
users7
websitedojotoolkit.org

People

Translate

site design / logo © 2021 Grokbase