FAQ

[dojo-contributors] Code style change (was Re: Allow multiple dojo versions in a page for 1.1?)

James Burke
Jan 11, 2008 at 10:36 pm
I just committed a set of changes that allows multiple versions of
dojo in a page. As a result, there is a new style guide rule (I
updated the guide to reflect this):

When constructing string IDs or ID prefixes in the code, do not use
"dojo", "dijit" or "dojox" in the names. Because we now allow multiple
versions of dojo in a page, it is important you use _scopeName instead
(dojo._scopeName, dijit._scopeName, dojox._scopeName).

I tried to change the places where I thought this rule applied. Be
sure to check out the changeset below to see if your favorite module
has changed:
Core: http://trac.dojotoolkit.org/changeset/12008
Dijit: http://trac.dojotoolkit.org/changeset/12010
Dojox: http://trac.dojotoolkit.org/changeset/12011

There were some things that may be candidates for _scopeName, but I
was not sure. Just calling them out in case you want to review for
yourselves:
- dojox.dtl: some registration going on?
- dojox.wire _wireClasses?
- No dojox flash things were updated, since the .as files do not have
access to the _scopeName property.
- dojox/presentation/_base.js: getSiblingsByType. May be problematic?

I ran the Core unit tests in all the major browsers and ran the
dojox.data tests. I ran themeTester.html in IE 6. I think everything
is OK, but I could have missed something. Just holler if I did, and
I'll fix it asap.

If you are curious how to use this functionality, you can see the
source for test files that start with "scope" in this folder:
http://trac.dojotoolkit.org/browser/dojo/trunk/tests/_base/_loader

Once I clean up some loose ends (really just xdomain debugAtAllCosts
support) then I'll being doing some doc updates.

James
On Dec 30, 2007 9:29 AM, James Burke wrote:
I've been working on a change that would allow running more than one
version of Dojo in the page:
http://trac.dojotoolkit.org/ticket/4573

I will likely start applying the change in about a week, but it has
some coding implications. You may not feel the changes are worth the
added benefit. If so, please speak up now, and if it seems like we
generally do not like the tradeoffs, then I will not do the code
changes.

Benefits:
==============
1) Allows someone that provides a JS library to use dojo underneath
the covers, but that version of Dojo would not interfere with another
version used on the page. It also means that other version on the page
will not interfere with the version used by the JS library. Example:
Mapquest could use some of Dojo's gfx code to help with doing map
drawings, and this code could be used in many different sites which
may use different versions of Dojo (disclaimer: Mapquest is owned by
AOL, I work for AOL. I have not talked with the Mapquest team about
this, so I do not know if they need this capability, I am
extrapolating).

2) Might allow easier code migration to 1.x from 0.4.

3) The code changes will work for modules outside of the blessed dojo
modules. There is some special consideration in xdomain builds (you
have to know all the 3rd party module prefixes you are going to use up
front before you do the xdomain build), but otherwise you can multiple
versions of your own modules in a page.

Code impact:
==============
1) Some of the code uses "dojo" or "dijit" for node names or IDs. That
code would be changed to use dojo._scopeName and dijit._scopeName.
After this code change, you will need to make sure you use the new
_scopeName properties when making strings that are based on the module
name. Note that css class names would not change. I figure it is
easier for people to wrap the code in a container element and apply a
unique class/ID on that container to get different styles (similar to
how we allow for multiple themes in a page).

2) You do not have to change how you reference dojo, dijit or dojox in
your code. The code works by enclosing loaded module resources in an
anonymous function that sets the dojo, dijit, dojox (and your own
custom prefixes). However, this means that dojo will never support
defining a loose function in a module and have it bind to the window
object. For instance defining:

function foo() { /*do something*/ }

in your module file means that it will not be visible as window.foo.
This limitation is already there for xdomain builds and for IE with
the normal dojo loader, but this change will now make this limitation
uniform. I think this is good, since dojo's behavior will always be
uniform and it encourages proper namespacing of code, but it can cause
issues for people assuming module files work just like normal files
attached directly via script elements.

3) I want to copy the djConfig object inside the dojo object. This
will allow multiple versions to change the djConfig object with
minimal effect on other versions that may want different djConfig
settings. This means in the future instead of referencing djConfig
directly, you would reference dojo.config or dojo.cfg or something
like that.

4) After I do this change you will have to be very careful about doing
code merges to and from the 1.0 branch (I think trunk is starting to
drift away from the 1.0 tree though, so you probably should be careful
anyway).

Example
=============
I have an example page working here:
http://dojotoolkit.org/~jburke/scope/dojo/tests/_base/_loader/scope04.html

One additional thing I want to add to what is working in the test page
is the ability to do dojo10.require("dojo10.parser"). I still want to
support dojo10.require("dojo.parser") too (it works and loads the
right version already), but I think being able to specify
"dojo10.parser" might make it clearer for the developer working with a
specific scope name.

Also, I'm using names like scopeMap and scopeName for setting up this
new capability. Holler if you think these are bad names.

I'll start the code changes in about a week, unless there is feedback
to the contrary.

James
reply

Search Discussions

14 responses

  • Michael Smith at Jan 12, 2008 at 3:51 am
    This looks great. Does this mean that 1.1 will be able to coexist with 0.4.x,
    0.9, or 1.0 versions? Or is this only effective for multiple versions that
    are 1.1+?

    Thanks for the good work.
    ~Michael

    On Jan 11, 2008 7:36 PM, James Burke wrote:

    I just committed a set of changes that allows multiple versions of
    dojo in a page. As a result, there is a new style guide rule (I
    updated the guide to reflect this):

    When constructing string IDs or ID prefixes in the code, do not use
    "dojo", "dijit" or "dojox" in the names. Because we now allow multiple
    versions of dojo in a page, it is important you use _scopeName instead
    (dojo._scopeName, dijit._scopeName, dojox._scopeName).

    I tried to change the places where I thought this rule applied. Be
    sure to check out the changeset below to see if your favorite module
    has changed:
    Core: http://trac.dojotoolkit.org/changeset/12008
    Dijit: http://trac.dojotoolkit.org/changeset/12010
    Dojox: http://trac.dojotoolkit.org/changeset/12011

    There were some things that may be candidates for _scopeName, but I
    was not sure. Just calling them out in case you want to review for
    yourselves:
    - dojox.dtl: some registration going on?
    - dojox.wire _wireClasses?
    - No dojox flash things were updated, since the .as files do not have
    access to the _scopeName property.
    - dojox/presentation/_base.js: getSiblingsByType. May be problematic?

    I ran the Core unit tests in all the major browsers and ran the
    dojox.data tests. I ran themeTester.html in IE 6. I think everything
    is OK, but I could have missed something. Just holler if I did, and
    I'll fix it asap.

    If you are curious how to use this functionality, you can see the
    source for test files that start with "scope" in this folder:
    http://trac.dojotoolkit.org/browser/dojo/trunk/tests/_base/_loader

    Once I clean up some loose ends (really just xdomain debugAtAllCosts
    support) then I'll being doing some doc updates.

    James
    On Dec 30, 2007 9:29 AM, James Burke wrote:
    I've been working on a change that would allow running more than one
    version of Dojo in the page:
    http://trac.dojotoolkit.org/ticket/4573

    I will likely start applying the change in about a week, but it has
    some coding implications. You may not feel the changes are worth the
    added benefit. If so, please speak up now, and if it seems like we
    generally do not like the tradeoffs, then I will not do the code
    changes.

    Benefits:
    ==============
    1) Allows someone that provides a JS library to use dojo underneath
    the covers, but that version of Dojo would not interfere with another
    version used on the page. It also means that other version on the page
    will not interfere with the version used by the JS library. Example:
    Mapquest could use some of Dojo's gfx code to help with doing map
    drawings, and this code could be used in many different sites which
    may use different versions of Dojo (disclaimer: Mapquest is owned by
    AOL, I work for AOL. I have not talked with the Mapquest team about
    this, so I do not know if they need this capability, I am
    extrapolating).

    2) Might allow easier code migration to 1.x from 0.4.

    3) The code changes will work for modules outside of the blessed dojo
    modules. There is some special consideration in xdomain builds (you
    have to know all the 3rd party module prefixes you are going to use up
    front before you do the xdomain build), but otherwise you can multiple
    versions of your own modules in a page.

    Code impact:
    ==============
    1) Some of the code uses "dojo" or "dijit" for node names or IDs. That
    code would be changed to use dojo._scopeName and dijit._scopeName.
    After this code change, you will need to make sure you use the new
    _scopeName properties when making strings that are based on the module
    name. Note that css class names would not change. I figure it is
    easier for people to wrap the code in a container element and apply a
    unique class/ID on that container to get different styles (similar to
    how we allow for multiple themes in a page).

    2) You do not have to change how you reference dojo, dijit or dojox in
    your code. The code works by enclosing loaded module resources in an
    anonymous function that sets the dojo, dijit, dojox (and your own
    custom prefixes). However, this means that dojo will never support
    defining a loose function in a module and have it bind to the window
    object. For instance defining:

    function foo() { /*do something*/ }

    in your module file means that it will not be visible as window.foo.
    This limitation is already there for xdomain builds and for IE with
    the normal dojo loader, but this change will now make this limitation
    uniform. I think this is good, since dojo's behavior will always be
    uniform and it encourages proper namespacing of code, but it can cause
    issues for people assuming module files work just like normal files
    attached directly via script elements.

    3) I want to copy the djConfig object inside the dojo object. This
    will allow multiple versions to change the djConfig object with
    minimal effect on other versions that may want different djConfig
    settings. This means in the future instead of referencing djConfig
    directly, you would reference dojo.config or dojo.cfg or something
    like that.

    4) After I do this change you will have to be very careful about doing
    code merges to and from the 1.0 branch (I think trunk is starting to
    drift away from the 1.0 tree though, so you probably should be careful
    anyway).

    Example
    =============
    I have an example page working here:
    http://dojotoolkit.org/~jburke/scope/dojo/tests/_base/_loader/scope04.html<http://dojotoolkit.org/%7Ejburke/scope/dojo/tests/_base/_loader/scope04.html>
    One additional thing I want to add to what is working in the test page
    is the ability to do dojo10.require("dojo10.parser"). I still want to
    support dojo10.require("dojo.parser") too (it works and loads the
    right version already), but I think being able to specify
    "dojo10.parser" might make it clearer for the developer working with a
    specific scope name.

    Also, I'm using names like scopeMap and scopeName for setting up this
    new capability. Holler if you think these are bad names.

    I'll start the code changes in about a week, unless there is feedback
    to the contrary.

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20080112/9775ede0/attachment.htm
  • James Burke at Jan 12, 2008 at 10:14 am
    A 1.1 version can coexist with 0.4+ (as long as there is a
    djConfig.scopeMap). One of the tests demonstrates 0.4 and 1.1
    coexistence:

    http://trac.dojotoolkit.org/browser/dojo/trunk/tests/_base/_loader/scope04.html

    James
    On Jan 12, 2008 12:51 AM, Michael Smith wrote:
    This looks great. Does this mean that 1.1 will be able to coexist with
    0.4.x, 0.9, or 1.0 versions? Or is this only effective for multiple versions
    that are 1.1+?

    Thanks for the good work.
    ~Michael



    On Jan 11, 2008 7:36 PM, James Burke wrote:



    I just committed a set of changes that allows multiple versions of
    dojo in a page. As a result, there is a new style guide rule (I
    updated the guide to reflect this):

    When constructing string IDs or ID prefixes in the code, do not use
    "dojo", "dijit" or "dojox" in the names. Because we now allow multiple
    versions of dojo in a page, it is important you use _scopeName instead
    (dojo._scopeName, dijit._scopeName, dojox._scopeName).

    I tried to change the places where I thought this rule applied. Be
    sure to check out the changeset below to see if your favorite module
    has changed:
    Core: http://trac.dojotoolkit.org/changeset/12008
    Dijit: http://trac.dojotoolkit.org/changeset/12010
    Dojox: http://trac.dojotoolkit.org/changeset/12011

    There were some things that may be candidates for _scopeName, but I
    was not sure. Just calling them out in case you want to review for
    yourselves:
    - dojox.dtl : some registration going on?
    - dojox.wire _wireClasses?
    - No dojox flash things were updated, since the .as files do not have
    access to the _scopeName property.
    - dojox/presentation/_base.js: getSiblingsByType. May be problematic?

    I ran the Core unit tests in all the major browsers and ran the
    dojox.data tests. I ran themeTester.html in IE 6. I think everything
    is OK, but I could have missed something. Just holler if I did, and
    I'll fix it asap.

    If you are curious how to use this functionality, you can see the
    source for test files that start with "scope" in this folder:
    http://trac.dojotoolkit.org/browser/dojo/trunk/tests/_base/_loader

    Once I clean up some loose ends (really just xdomain debugAtAllCosts
    support) then I'll being doing some doc updates.

    James
    On Dec 30, 2007 9:29 AM, James Burke wrote:
    I've been working on a change that would allow running more than one
    version of Dojo in the page:
    http://trac.dojotoolkit.org/ticket/4573

    I will likely start applying the change in about a week, but it has
    some coding implications. You may not feel the changes are worth the
    added benefit. If so, please speak up now, and if it seems like we
    generally do not like the tradeoffs, then I will not do the code
    changes.

    Benefits:
    ==============
    1) Allows someone that provides a JS library to use dojo underneath
    the covers, but that version of Dojo would not interfere with another
    version used on the page. It also means that other version on the page
    will not interfere with the version used by the JS library. Example:
    Mapquest could use some of Dojo's gfx code to help with doing map
    drawings, and this code could be used in many different sites which
    may use different versions of Dojo (disclaimer: Mapquest is owned by
    AOL, I work for AOL. I have not talked with the Mapquest team about
    this, so I do not know if they need this capability, I am
    extrapolating).

    2) Might allow easier code migration to 1.x from 0.4.

    3) The code changes will work for modules outside of the blessed dojo
    modules. There is some special consideration in xdomain builds (you
    have to know all the 3rd party module prefixes you are going to use up
    front before you do the xdomain build), but otherwise you can multiple
    versions of your own modules in a page.

    Code impact:
    ==============
    1) Some of the code uses "dojo" or "dijit" for node names or IDs. That
    code would be changed to use dojo._scopeName and dijit._scopeName.
    After this code change, you will need to make sure you use the new
    _scopeName properties when making strings that are based on the module
    name. Note that css class names would not change. I figure it is
    easier for people to wrap the code in a container element and apply a
    unique class/ID on that container to get different styles (similar to
    how we allow for multiple themes in a page).

    2) You do not have to change how you reference dojo, dijit or dojox in
    your code. The code works by enclosing loaded module resources in an
    anonymous function that sets the dojo, dijit, dojox (and your own
    custom prefixes). However, this means that dojo will never support
    defining a loose function in a module and have it bind to the window
    object. For instance defining:

    function foo() { /*do something*/ }

    in your module file means that it will not be visible as window.foo.
    This limitation is already there for xdomain builds and for IE with
    the normal dojo loader, but this change will now make this limitation
    uniform. I think this is good, since dojo's behavior will always be
    uniform and it encourages proper namespacing of code, but it can cause
    issues for people assuming module files work just like normal files
    attached directly via script elements.

    3) I want to copy the djConfig object inside the dojo object. This
    will allow multiple versions to change the djConfig object with
    minimal effect on other versions that may want different djConfig
    settings. This means in the future instead of referencing djConfig
    directly, you would reference dojo.config or dojo.cfg or something
    like that.

    4) After I do this change you will have to be very careful about doing
    code merges to and from the 1.0 branch (I think trunk is starting to
    drift away from the 1.0 tree though, so you probably should be careful
    anyway).

    Example
    =============
    I have an example page working here:
    http://dojotoolkit.org/~jburke/scope/dojo/tests/_base/_loader/scope04.html
    One additional thing I want to add to what is working in the test page
    is the ability to do dojo10.require("dojo10.parser"). I still want to
    support dojo10.require("dojo.parser ") too (it works and loads the
    right version already), but I think being able to specify
    "dojo10.parser" might make it clearer for the developer working with a
    specific scope name.

    Also, I'm using names like scopeMap and scopeName for setting up this
    new capability. Holler if you think these are bad names.

    I'll start the code changes in about a week, unless there is feedback
    to the contrary.

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Shane O'Sullivan at Jan 21, 2008 at 4:54 pm
    How does this work with <script> including files? When I specify the
    scopemap from the trunk code, and include some dojox files, an error
    is thrown saying that dojox is not defined. dojox10 is defined
    instead.

    So, does this only work if dojo10.require() is used? Does that
    automatically replace references in 'dojox' with 'dojox10', or how
    does it work?

    Thanks

    Shane
    On 12/01/2008, James Burke wrote:
    A 1.1 version can coexist with 0.4+ (as long as there is a
    djConfig.scopeMap). One of the tests demonstrates 0.4 and 1.1
    coexistence:

    http://trac.dojotoolkit.org/browser/dojo/trunk/tests/_base/_loader/scope04.html

    James
    On Jan 12, 2008 12:51 AM, Michael Smith wrote:
    This looks great. Does this mean that 1.1 will be able to coexist with
    0.4.x, 0.9, or 1.0 versions? Or is this only effective for multiple versions
    that are 1.1+?

    Thanks for the good work.
    ~Michael



    On Jan 11, 2008 7:36 PM, James Burke wrote:



    I just committed a set of changes that allows multiple versions of
    dojo in a page. As a result, there is a new style guide rule (I
    updated the guide to reflect this):

    When constructing string IDs or ID prefixes in the code, do not use
    "dojo", "dijit" or "dojox" in the names. Because we now allow multiple
    versions of dojo in a page, it is important you use _scopeName instead
    (dojo._scopeName, dijit._scopeName, dojox._scopeName).

    I tried to change the places where I thought this rule applied. Be
    sure to check out the changeset below to see if your favorite module
    has changed:
    Core: http://trac.dojotoolkit.org/changeset/12008
    Dijit: http://trac.dojotoolkit.org/changeset/12010
    Dojox: http://trac.dojotoolkit.org/changeset/12011

    There were some things that may be candidates for _scopeName, but I
    was not sure. Just calling them out in case you want to review for
    yourselves:
    - dojox.dtl : some registration going on?
    - dojox.wire _wireClasses?
    - No dojox flash things were updated, since the .as files do not have
    access to the _scopeName property.
    - dojox/presentation/_base.js: getSiblingsByType. May be problematic?

    I ran the Core unit tests in all the major browsers and ran the
    dojox.data tests. I ran themeTester.html in IE 6. I think everything
    is OK, but I could have missed something. Just holler if I did, and
    I'll fix it asap.

    If you are curious how to use this functionality, you can see the
    source for test files that start with "scope" in this folder:
    http://trac.dojotoolkit.org/browser/dojo/trunk/tests/_base/_loader

    Once I clean up some loose ends (really just xdomain debugAtAllCosts
    support) then I'll being doing some doc updates.

    James
    On Dec 30, 2007 9:29 AM, James Burke wrote:
    I've been working on a change that would allow running more than one
    version of Dojo in the page:
    http://trac.dojotoolkit.org/ticket/4573

    I will likely start applying the change in about a week, but it has
    some coding implications. You may not feel the changes are worth the
    added benefit. If so, please speak up now, and if it seems like we
    generally do not like the tradeoffs, then I will not do the code
    changes.

    Benefits:
    ==============
    1) Allows someone that provides a JS library to use dojo underneath
    the covers, but that version of Dojo would not interfere with another
    version used on the page. It also means that other version on the page
    will not interfere with the version used by the JS library. Example:
    Mapquest could use some of Dojo's gfx code to help with doing map
    drawings, and this code could be used in many different sites which
    may use different versions of Dojo (disclaimer: Mapquest is owned by
    AOL, I work for AOL. I have not talked with the Mapquest team about
    this, so I do not know if they need this capability, I am
    extrapolating).

    2) Might allow easier code migration to 1.x from 0.4.

    3) The code changes will work for modules outside of the blessed dojo
    modules. There is some special consideration in xdomain builds (you
    have to know all the 3rd party module prefixes you are going to use up
    front before you do the xdomain build), but otherwise you can multiple
    versions of your own modules in a page.

    Code impact:
    ==============
    1) Some of the code uses "dojo" or "dijit" for node names or IDs. That
    code would be changed to use dojo._scopeName and dijit._scopeName.
    After this code change, you will need to make sure you use the new
    _scopeName properties when making strings that are based on the module
    name. Note that css class names would not change. I figure it is
    easier for people to wrap the code in a container element and apply a
    unique class/ID on that container to get different styles (similar to
    how we allow for multiple themes in a page).

    2) You do not have to change how you reference dojo, dijit or dojox in
    your code. The code works by enclosing loaded module resources in an
    anonymous function that sets the dojo, dijit, dojox (and your own
    custom prefixes). However, this means that dojo will never support
    defining a loose function in a module and have it bind to the window
    object. For instance defining:

    function foo() { /*do something*/ }

    in your module file means that it will not be visible as window.foo.
    This limitation is already there for xdomain builds and for IE with
    the normal dojo loader, but this change will now make this limitation
    uniform. I think this is good, since dojo's behavior will always be
    uniform and it encourages proper namespacing of code, but it can cause
    issues for people assuming module files work just like normal files
    attached directly via script elements.

    3) I want to copy the djConfig object inside the dojo object. This
    will allow multiple versions to change the djConfig object with
    minimal effect on other versions that may want different djConfig
    settings. This means in the future instead of referencing djConfig
    directly, you would reference dojo.config or dojo.cfg or something
    like that.

    4) After I do this change you will have to be very careful about doing
    code merges to and from the 1.0 branch (I think trunk is starting to
    drift away from the 1.0 tree though, so you probably should be careful
    anyway).

    Example
    =============
    I have an example page working here:
    http://dojotoolkit.org/~jburke/scope/dojo/tests/_base/_loader/scope04.html
    One additional thing I want to add to what is working in the test page
    is the ability to do dojo10.require("dojo10.parser"). I still want to
    support dojo10.require("dojo.parser ") too (it works and loads the
    right version already), but I think being able to specify
    "dojo10.parser" might make it clearer for the developer working with a
    specific scope name.

    Also, I'm using names like scopeMap and scopeName for setting up this
    new capability. Holler if you think these are bad names.

    I'll start the code changes in about a week, unless there is feedback
    to the contrary.

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • James Burke at Jan 21, 2008 at 5:55 pm

    On Jan 21, 2008 1:54 PM, Shane O'Sullivan wrote:
    How does this work with <script> including files? When I specify the
    scopemap from the trunk code, and include some dojox files, an error
    is thrown saying that dojox is not defined. dojox10 is defined
    instead.

    So, does this only work if dojo10.require() is used? Does that
    automatically replace references in 'dojox' with 'dojox10', or how
    does it work?
    Yes, it breaks with script-included files. The scope mechanism works
    by wrapping any code that is dojo.required in a function that defines
    what dojo, dijit and dojox really are. For example, it does something
    like this after fetching the module's source with XHR:

    eval("(function(dojo, dijit, dojox){
    //Your module's code goes in here
    })(dojo10, dijit10, dojox10);");

    (the xdomain thing does something similar, but you have to know the
    scope values at build time for anything beyond dojo, dijit and dojox)

    This has the benefit that we don't have to do some sort of complex
    regexp work at runtime or buildtime. I'm not confident we could catch
    all the cases using regexps. And it means we can support scoping with
    a default build of dojo (we do not have to make the scoping decision
    at build time -- we can do it at runtime). However it does break
    things if you are trying to manually import code via script tags.

    I will be adding a feature to debugAtAllCosts where if you are using
    the scoping stuff, it will create a globally visible dojo, dijit and
    dojox and bind them to the dojo10, dijit10, dojox10 (for instance)
    variables. This should then allow for doing the normal debugging you
    get with inlined script tags.

    *However*, the debugAtAllCosts global thing will make it hard if you
    are trying to debug your scoped code with other code on the page that
    is using dojo. At that point, I suggest doing a custom build of your
    scoped code so that everything is in a built, scoped dojo.js and
    proceed from there. That is what I consider the common workflow case
    (at least in the future):

    - You want to provide a library that uses dojo underneath, but you
    want to scope it to a different name, say "foo", "fijit" and "fojox".
    - You develop your library using the scope hooks, but you do not use a
    custom build and at this point you are not mixing with other dojo
    versions -- you are just developing your code. In this case you can
    use the debugAtAllCosts flag to help in your debugging (after I do the
    changes mentioned above).
    - You get it working, then you do your custom build, and deliver your
    foo.js for others to use.
    - Other people can use your foo.js in a page with other dojo code. If
    they need to debug, hopefully your foo.js is self contained, and the
    debugAtAllCosts debugging will only affect the other dojo. There will
    also be a build option to burn in a local djConfig so that your
    library code does not get weird djConfig values from the other dojo.

    For the other workflow where you have a Dojo 0.4.3 app and want to mix
    in Dojo 1.1, then it will require more work -- most likely doing some
    custom builds of the scoped 1.1 so everything is in one dojo.js file
    that you can import. Even though this use case is more work and
    probably the more common case right now, I expect this use case to
    shrink to zero with the other use case above being the majority case.

    Hopefully that explains the tradeoffs and why I'm favoring the "make
    your own library with dojo" case over the "gradually migrate my app
    from 0.4.3 to 1.x" case. I'm happy to hear feedback though. I did this
    work mostly in isolation, so I may have missed the mark for what we
    want.

    James
  • Shane O'Sullivan at Jan 21, 2008 at 6:10 pm
    I think the "gradually migrate" use case is definitely a very common
    one - my company's client infrastructure is currently very dependent
    on 0.4.3, and after our major release in a few weeks, we will begin to
    upgrade to 1.x. Having this functionality work for that case would be
    extremely useful to us.

    Since you are wrapping all calls to dojo.require() with a private
    function defining the scope map, would it not also make sense to do
    the same in the optional build step - for each JS file that can be
    dojo.require'd, wrap it's contents in that private function. Would
    this not function just the same as dojo.require, and work also for
    script includes? It would also remove the need for easily breakable
    regexs

    Thanks

    Shane
    On 21/01/2008, James Burke wrote:
    On Jan 21, 2008 1:54 PM, Shane O'Sullivan wrote:
    How does this work with <script> including files? When I specify the
    scopemap from the trunk code, and include some dojox files, an error
    is thrown saying that dojox is not defined. dojox10 is defined
    instead.

    So, does this only work if dojo10.require() is used? Does that
    automatically replace references in 'dojox' with 'dojox10', or how
    does it work?
    Yes, it breaks with script-included files. The scope mechanism works
    by wrapping any code that is dojo.required in a function that defines
    what dojo, dijit and dojox really are. For example, it does something
    like this after fetching the module's source with XHR:

    eval("(function(dojo, dijit, dojox){
    //Your module's code goes in here
    })(dojo10, dijit10, dojox10);");

    (the xdomain thing does something similar, but you have to know the
    scope values at build time for anything beyond dojo, dijit and dojox)

    This has the benefit that we don't have to do some sort of complex
    regexp work at runtime or buildtime. I'm not confident we could catch
    all the cases using regexps. And it means we can support scoping with
    a default build of dojo (we do not have to make the scoping decision
    at build time -- we can do it at runtime). However it does break
    things if you are trying to manually import code via script tags.

    I will be adding a feature to debugAtAllCosts where if you are using
    the scoping stuff, it will create a globally visible dojo, dijit and
    dojox and bind them to the dojo10, dijit10, dojox10 (for instance)
    variables. This should then allow for doing the normal debugging you
    get with inlined script tags.

    *However*, the debugAtAllCosts global thing will make it hard if you
    are trying to debug your scoped code with other code on the page that
    is using dojo. At that point, I suggest doing a custom build of your
    scoped code so that everything is in a built, scoped dojo.js and
    proceed from there. That is what I consider the common workflow case
    (at least in the future):

    - You want to provide a library that uses dojo underneath, but you
    want to scope it to a different name, say "foo", "fijit" and "fojox".
    - You develop your library using the scope hooks, but you do not use a
    custom build and at this point you are not mixing with other dojo
    versions -- you are just developing your code. In this case you can
    use the debugAtAllCosts flag to help in your debugging (after I do the
    changes mentioned above).
    - You get it working, then you do your custom build, and deliver your
    foo.js for others to use.
    - Other people can use your foo.js in a page with other dojo code. If
    they need to debug, hopefully your foo.js is self contained, and the
    debugAtAllCosts debugging will only affect the other dojo. There will
    also be a build option to burn in a local djConfig so that your
    library code does not get weird djConfig values from the other dojo.

    For the other workflow where you have a Dojo 0.4.3 app and want to mix
    in Dojo 1.1, then it will require more work -- most likely doing some
    custom builds of the scoped 1.1 so everything is in one dojo.js file
    that you can import. Even though this use case is more work and
    probably the more common case right now, I expect this use case to
    shrink to zero with the other use case above being the majority case.

    Hopefully that explains the tradeoffs and why I'm favoring the "make
    your own library with dojo" case over the "gradually migrate my app
    from 0.4.3 to 1.x" case. I'm happy to hear feedback though. I did this
    work mostly in isolation, so I may have missed the mark for what we
    want.

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • James Burke at Jan 21, 2008 at 9:59 pm

    On Jan 21, 2008 3:10 PM, Shane O'Sullivan wrote:
    I think the "gradually migrate" use case is definitely a very common
    one - my company's client infrastructure is currently very dependent
    on 0.4.3, and after our major release in a few weeks, we will begin to
    upgrade to 1.x. Having this functionality work for that case would be
    extremely useful to us.
    The functionality can work for that case, but it requires build step
    iteration for the 1.1 code, if you want to do something like
    debugAtAllCosts. If you do not need to do debugAtAllCosts then you can
    use the functionality as-is, in particular after I get the changes in
    for local djConfig values (so the 1.1 version will not be in
    debugAtAllCosts mode, but the other version can be).
    Since you are wrapping all calls to dojo.require() with a private
    function defining the scope map, would it not also make sense to do
    the same in the optional build step - for each JS file that can be
    dojo.require'd, wrap it's contents in that private function. Would
    this not function just the same as dojo.require, and work also for
    script includes? It would also remove the need for easily breakable
    regexs
    This means though that if you develop any new modules, as you are
    developing, they would not fit into the scoped model. You would have
    to do a build every time you did a code change. This seems like an
    undesirably high development cost. Having the function wrapper done in
    the loader instead of every file avoids that issue.

    I think the larger issue is why are you doing the script includes? Is
    it for debugging? Do you find debugAtAllCosts not an acceptable
    solution in that case?

    [start larger philosophical issue]

    I have always been concerned that our loaders do not function the same
    as direct script tags. We get some tangible benefits though from our
    different behavior: dependency resolution, xdomain (CDN) loading, and
    now multiple version support.

    What we give up though is that the modules are not evaluated in the
    same scope as compared to plain script tags. Also, in the default
    loader case, trouble debugging because of the use of eval.

    There may be a way to get dependency resolution without using eval (IE
    and Safari use a different scope when we use eval):
    http://webreflection.blogspot.com/2007/08/global-scope-evaluation-and-dom.html

    (Blog post from Andrea Giammarchi. Basically, create a script node and
    do node.text = script or node.appendChild(textNodeWithScript). This is
    what jQuery 1.2.2 seems to do for one of their methods, and it is
    inspired from the blog post above).

    I do not think this would help the debugging case though. I tried
    something earlier with scriptNode.text in Firefox, but Firebug did not
    seem to be able to recognize it as something that was debuggable:
    http://groups.google.com/group/firebug/browse_thread/thread/41080497659c1423?hl=en

    And if we want to maintain the xdomain and multiple version support,
    the scope will still be different. So I do not see any good
    alternatives to our current loader approaches, particularly since we
    have debugAtAllCosts, which does attach scripts to the DOM.

    The downside is we have a case where debugAtAllCosts breaks down:
    using scoped code with the normal dojo loader when there is another
    version of dojo in the page. It is workable (do a build, or test the
    scoped code separately from the page that has the other dojo) but at
    this point, I think that slight awkwardness is outweighed by the
    benefit of just being able to run two versions of dojo in the page.

    But I'm really open to ideas on how to make that case better. Keep the
    ideas coming.

    [end larger philosophical issue]

    James


    Thanks

    Shane

    On 21/01/2008, James Burke wrote:
    On Jan 21, 2008 1:54 PM, Shane O'Sullivan wrote:
    How does this work with <script> including files? When I specify the
    scopemap from the trunk code, and include some dojox files, an error
    is thrown saying that dojox is not defined. dojox10 is defined
    instead.

    So, does this only work if dojo10.require() is used? Does that
    automatically replace references in 'dojox' with 'dojox10', or how
    does it work?
    Yes, it breaks with script-included files. The scope mechanism works
    by wrapping any code that is dojo.required in a function that defines
    what dojo, dijit and dojox really are. For example, it does something
    like this after fetching the module's source with XHR:

    eval("(function(dojo, dijit, dojox){
    //Your module's code goes in here
    })(dojo10, dijit10, dojox10);");

    (the xdomain thing does something similar, but you have to know the
    scope values at build time for anything beyond dojo, dijit and dojox)

    This has the benefit that we don't have to do some sort of complex
    regexp work at runtime or buildtime. I'm not confident we could catch
    all the cases using regexps. And it means we can support scoping with
    a default build of dojo (we do not have to make the scoping decision
    at build time -- we can do it at runtime). However it does break
    things if you are trying to manually import code via script tags.

    I will be adding a feature to debugAtAllCosts where if you are using
    the scoping stuff, it will create a globally visible dojo, dijit and
    dojox and bind them to the dojo10, dijit10, dojox10 (for instance)
    variables. This should then allow for doing the normal debugging you
    get with inlined script tags.

    *However*, the debugAtAllCosts global thing will make it hard if you
    are trying to debug your scoped code with other code on the page that
    is using dojo. At that point, I suggest doing a custom build of your
    scoped code so that everything is in a built, scoped dojo.js and
    proceed from there. That is what I consider the common workflow case
    (at least in the future):

    - You want to provide a library that uses dojo underneath, but you
    want to scope it to a different name, say "foo", "fijit" and "fojox".
    - You develop your library using the scope hooks, but you do not use a
    custom build and at this point you are not mixing with other dojo
    versions -- you are just developing your code. In this case you can
    use the debugAtAllCosts flag to help in your debugging (after I do the
    changes mentioned above).
    - You get it working, then you do your custom build, and deliver your
    foo.js for others to use.
    - Other people can use your foo.js in a page with other dojo code. If
    they need to debug, hopefully your foo.js is self contained, and the
    debugAtAllCosts debugging will only affect the other dojo. There will
    also be a build option to burn in a local djConfig so that your
    library code does not get weird djConfig values from the other dojo.

    For the other workflow where you have a Dojo 0.4.3 app and want to mix
    in Dojo 1.1, then it will require more work -- most likely doing some
    custom builds of the scoped 1.1 so everything is in one dojo.js file
    that you can import. Even though this use case is more work and
    probably the more common case right now, I expect this use case to
    shrink to zero with the other use case above being the majority case.

    Hopefully that explains the tradeoffs and why I'm favoring the "make
    your own library with dojo" case over the "gradually migrate my app
    from 0.4.3 to 1.x" case. I'm happy to hear feedback though. I did this
    work mostly in isolation, so I may have missed the mark for what we
    want.

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Shane O'Sullivan at Jan 22, 2008 at 4:15 am
    Hi James,

    Answers inline:
    I think the larger issue is why are you doing the script includes?
    Script includes should always be used in any high-traffic site. Since
    dojo.require calls are no browser cached, they will be pulled down
    every time. I would imagine that everyone who is writing non-hobbyist
    websites will use script includes for the majority of their code,
    leaving dojo.require for the development stage, and for loading
    optional code (e.g. browser specific stuff like SVG) or i18n
    resources.

    Therefore, putting this functionality only in the dojo.require is
    basically telling most people that in order for them to use it, their
    sites have to take a big performance hit.
    You would have to do a build every time you did a code change
    Not necessarily. You could script include a file that is replaced by
    a built layer, similar to the dijit-all.js file. So, at development
    time, you will be using dojo.require statements (which are all that
    are included in the layer file) and at build time the same file is
    replaced with the built/compressed code, already surrounded by the
    scoped function

    Thanks

    Shane
    On 22/01/2008, James Burke wrote:
    On Jan 21, 2008 3:10 PM, Shane O'Sullivan wrote:
    I think the "gradually migrate" use case is definitely a very common
    one - my company's client infrastructure is currently very dependent
    on 0.4.3, and after our major release in a few weeks, we will begin to
    upgrade to 1.x. Having this functionality work for that case would be
    extremely useful to us.
    The functionality can work for that case, but it requires build step
    iteration for the 1.1 code, if you want to do something like
    debugAtAllCosts. If you do not need to do debugAtAllCosts then you can
    use the functionality as-is, in particular after I get the changes in
    for local djConfig values (so the 1.1 version will not be in
    debugAtAllCosts mode, but the other version can be).
    Since you are wrapping all calls to dojo.require() with a private
    function defining the scope map, would it not also make sense to do
    the same in the optional build step - for each JS file that can be
    dojo.require'd, wrap it's contents in that private function. Would
    this not function just the same as dojo.require, and work also for
    script includes? It would also remove the need for easily breakable
    regexs
    This means though that if you develop any new modules, as you are
    developing, they would not fit into the scoped model. You would have
    to do a build every time you did a code change. This seems like an
    undesirably high development cost. Having the function wrapper done in
    the loader instead of every file avoids that issue.

    I think the larger issue is why are you doing the script includes? Is
    it for debugging? Do you find debugAtAllCosts not an acceptable
    solution in that case?

    [start larger philosophical issue]

    I have always been concerned that our loaders do not function the same
    as direct script tags. We get some tangible benefits though from our
    different behavior: dependency resolution, xdomain (CDN) loading, and
    now multiple version support.

    What we give up though is that the modules are not evaluated in the
    same scope as compared to plain script tags. Also, in the default
    loader case, trouble debugging because of the use of eval.

    There may be a way to get dependency resolution without using eval (IE
    and Safari use a different scope when we use eval):
    http://webreflection.blogspot.com/2007/08/global-scope-evaluation-and-dom.html

    (Blog post from Andrea Giammarchi. Basically, create a script node and
    do node.text = script or node.appendChild(textNodeWithScript). This is
    what jQuery 1.2.2 seems to do for one of their methods, and it is
    inspired from the blog post above).

    I do not think this would help the debugging case though. I tried
    something earlier with scriptNode.text in Firefox, but Firebug did not
    seem to be able to recognize it as something that was debuggable:
    http://groups.google.com/group/firebug/browse_thread/thread/41080497659c1423?hl=en

    And if we want to maintain the xdomain and multiple version support,
    the scope will still be different. So I do not see any good
    alternatives to our current loader approaches, particularly since we
    have debugAtAllCosts, which does attach scripts to the DOM.

    The downside is we have a case where debugAtAllCosts breaks down:
    using scoped code with the normal dojo loader when there is another
    version of dojo in the page. It is workable (do a build, or test the
    scoped code separately from the page that has the other dojo) but at
    this point, I think that slight awkwardness is outweighed by the
    benefit of just being able to run two versions of dojo in the page.

    But I'm really open to ideas on how to make that case better. Keep the
    ideas coming.

    [end larger philosophical issue]

    James


    Thanks

    Shane

    On 21/01/2008, James Burke wrote:
    On Jan 21, 2008 1:54 PM, Shane O'Sullivan wrote:
    How does this work with <script> including files? When I specify the
    scopemap from the trunk code, and include some dojox files, an error
    is thrown saying that dojox is not defined. dojox10 is defined
    instead.

    So, does this only work if dojo10.require() is used? Does that
    automatically replace references in 'dojox' with 'dojox10', or how
    does it work?
    Yes, it breaks with script-included files. The scope mechanism works
    by wrapping any code that is dojo.required in a function that defines
    what dojo, dijit and dojox really are. For example, it does something
    like this after fetching the module's source with XHR:

    eval("(function(dojo, dijit, dojox){
    //Your module's code goes in here
    })(dojo10, dijit10, dojox10);");

    (the xdomain thing does something similar, but you have to know the
    scope values at build time for anything beyond dojo, dijit and dojox)

    This has the benefit that we don't have to do some sort of complex
    regexp work at runtime or buildtime. I'm not confident we could catch
    all the cases using regexps. And it means we can support scoping with
    a default build of dojo (we do not have to make the scoping decision
    at build time -- we can do it at runtime). However it does break
    things if you are trying to manually import code via script tags.

    I will be adding a feature to debugAtAllCosts where if you are using
    the scoping stuff, it will create a globally visible dojo, dijit and
    dojox and bind them to the dojo10, dijit10, dojox10 (for instance)
    variables. This should then allow for doing the normal debugging you
    get with inlined script tags.

    *However*, the debugAtAllCosts global thing will make it hard if you
    are trying to debug your scoped code with other code on the page that
    is using dojo. At that point, I suggest doing a custom build of your
    scoped code so that everything is in a built, scoped dojo.js and
    proceed from there. That is what I consider the common workflow case
    (at least in the future):

    - You want to provide a library that uses dojo underneath, but you
    want to scope it to a different name, say "foo", "fijit" and "fojox".
    - You develop your library using the scope hooks, but you do not use a
    custom build and at this point you are not mixing with other dojo
    versions -- you are just developing your code. In this case you can
    use the debugAtAllCosts flag to help in your debugging (after I do the
    changes mentioned above).
    - You get it working, then you do your custom build, and deliver your
    foo.js for others to use.
    - Other people can use your foo.js in a page with other dojo code. If
    they need to debug, hopefully your foo.js is self contained, and the
    debugAtAllCosts debugging will only affect the other dojo. There will
    also be a build option to burn in a local djConfig so that your
    library code does not get weird djConfig values from the other dojo.

    For the other workflow where you have a Dojo 0.4.3 app and want to mix
    in Dojo 1.1, then it will require more work -- most likely doing some
    custom builds of the scoped 1.1 so everything is in one dojo.js file
    that you can import. Even though this use case is more work and
    probably the more common case right now, I expect this use case to
    shrink to zero with the other use case above being the majority case.

    Hopefully that explains the tradeoffs and why I'm favoring the "make
    your own library with dojo" case over the "gradually migrate my app
    from 0.4.3 to 1.x" case. I'm happy to hear feedback though. I did this
    work mostly in isolation, so I may have missed the mark for what we
    want.

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • James Burke at Jan 25, 2008 at 3:55 pm
    Sorry for the delayed response (inline):
    On Jan 22, 2008 1:15 AM, Shane O'Sullivan wrote:
    I think the larger issue is why are you doing the script includes?
    Script includes should always be used in any high-traffic site. Since
    dojo.require calls are no browser cached, they will be pulled down
    every time. I would imagine that everyone who is writing non-hobbyist
    websites will use script includes for the majority of their code,
    leaving dojo.require for the development stage, and for loading
    optional code (e.g. browser specific stuff like SVG) or i18n
    resources.

    Therefore, putting this functionality only in the dojo.require is
    basically telling most people that in order for them to use it, their
    sites have to take a big performance hit.
    Or, use xdomain loading (which can be used even if serving everything
    from the same domain). Or do the build so that all the modules go in
    dojo.js. Those are both vaild performance-related options that work
    with the scoping.

    But I realize those two options are not always be desirable. I can see
    the benefit of having layer files wrapped in the function calls. I'm
    not sure yet how much more complication I want to put into this.
    You would have to do a build every time you did a code change
    Not necessarily. You could script include a file that is replaced by
    a built layer, similar to the dijit-all.js file. So, at development
    time, you will be using dojo.require statements (which are all that
    are included in the layer file) and at build time the same file is
    replaced with the built/compressed code, already surrounded by the
    scoped function
    That would only work in dev if you manually modify the script-included
    file to insert the function wrapper?

    I think the takeway is that it would be nice to support loading layer
    files via plain script tags, but not have to do an xdomain build. Does
    that sound right? My first inclination is to not support this. This
    means another build option and some additional hoops in development to
    get the scope right. If they have to learn another build option to get
    this to work, then why not learn the xdomain build? It will probably
    be important to them anyway if they want to look at high performance.

    Or they can just use the build option that puts all the layers in with
    dojo.js, that would also work. If they are using script tags to load
    things, they will likely get better performance just including it all
    as part of dojo.js. I know it is not our "standard use" suggestion (we
    normally say dojo.js should stay the same), but then again, I do not
    think multiversion support fits in our "standard use" suggestion
    either.

    I'm trying to walk the line of not giving too many degrees of freedom,
    particularly as we get into further "fringe" use cases, like
    multiversion support, but still have the feature usable.

    James
  • Shane O'Sullivan at Jan 25, 2008 at 7:58 pm
    Hi James,

    Answers inline
    That would only work in dev if you manually modify the script-included
    file to insert the function wrapper?
    Not so. If the file took the form:
    dojo.require("dijit.form.Button");
    dojo.require("dijit.form.FilteringSelect");
    etc, then at development time the dojo.require function call would
    take care of the scoping. The build system would then replace this
    file with the contents of the files that it dojo.require's, and wrap
    that in a function call, so that it'll work then too, without having
    to go through the dojo.require system.
    I think the takeway is that it would be nice to support loading layer
    files via plain script tags, but not have to do an xdomain build. Does
    that sound right?
    Precisely. Making it work with one approach and not the other could be
    very confusing, and will lead to many many user requests for the
    script tag method to work. Better to put it in now rather than have
    to add it later once people realise how cool this is but want it to
    work with browser caches.
    My first inclination is to not support this. This means another build option
    Not necessarily. You've already put in the build option to specify
    the scope names. We just change that option to perform the extra work
    needed, rather than just putting a single array into the bootstrap
    code, as is done now. This will give people a consistent behavior.
    For example, I personally was confused for a bit after I did my build
    that script including a file didn't work - I never dojo.require files
    unless absolutely necessary, so it didn't even occur to me to do so.
    I'm sure a lot of other people will find the same problem.
    Or they can just use the build option that puts all the layers in with
    dojo.js, that would also work.
    I think the fact that dojo.js always means the same thing is a very
    strong selling point of 1.x, and advising people to go back to the old
    ways is not the best way to go.
    I know it is not our "standard use" suggestion (we
    normally say dojo.js should stay the same),
    Great minds think alike :-)
    but then again, I do not think multiversion support fits in our "standard use" suggestion
    either.
    Hmm, just because it wasn't specifically brought up I think. The
    issue of what dojo.js should contain was decided upon very
    deliberately, for good reasons. I don't think it was ever thought
    "supporting multiple versions is a bad idea", it just wasn't pushed
    sufficiently by anyone. On that note, I'm very glad you have!
    I'm trying to walk the line of not giving too many degrees of freedom,
    particularly as we get into further "fringe" use cases, like
    multiversion support, but still have the feature usable.
    Agreed. However in this case, with the existing build option we can
    make this work both with dojo.require and with script tags, with no
    extra complexity than already exists.

    Thanks

    Shane
  • James Burke at Jan 27, 2008 at 12:40 am

    On Jan 25, 2008 4:58 PM, Shane O'Sullivan wrote:
    Hi James,

    Answers inline
    That would only work in dev if you manually modify the script-included
    file to insert the function wrapper?
    Not so. If the file took the form:
    dojo.require("dijit.form.Button");
    dojo.require("dijit.form.FilteringSelect");
    etc, then at development time the dojo.require function call would
    take care of the scoping. The build system would then replace this
    file with the contents of the files that it dojo.require's, and wrap
    that in a function call, so that it'll work then too, without having
    to go through the dojo.require system.
    Let's say you want to load a script named dojo/foo.js and it has these
    contents (it is basically like a layer file that will be replaced with
    inlined content once you do a build):
    dojo.provide("dojo.foo");
    dojo.require("dijit.form.Button");
    dojo.require("dijit.form.FilteringSelect");

    In development, you load this file via a script tag after dojo.js:
    <script type="text/javascript" src="dojo/foo.js"></script>

    Now suppose you configured dojo.js to use scopes via
    djConfig.scopeMap. The scopeMap configures dojo to really be bar in
    the global scope, dijit is bijit and dojox is barx. Once you do that,
    loading dojo/foo.js will break. "dojo" will not be exported out of
    dojo.js as a global (just "bar), so the contents of dojo/foo.js will
    call on a non-existent "dojo", resulting in an error.

    The only way to get this to work in dev is to manually change the
    contents of dojo/foo.js to this:
    (function(dojo, dijit, dojox){
    dojo.provide("dojo.foo");
    dojo.require("dijit.form.Button");
    dojo.require("dijit.form.FilteringSelect");
    })(bar, bijit, barx);

    To me, that is not a desirable solution to get this to work in dev. I
    much rather prefer to give our normal advice ("use dojo.require").
    I think the takeway is that it would be nice to support loading layer
    files via plain script tags, but not have to do an xdomain build. Does
    that sound right?
    Precisely. Making it work with one approach and not the other could be
    very confusing, and will lead to many many user requests for the
    script tag method to work. Better to put it in now rather than have
    to add it later once people realise how cool this is but want it to
    work with browser caches.
    My first inclination is to not support this. This means another build option
    Not necessarily. You've already put in the build option to specify
    the scope names. We just change that option to perform the extra work
    needed, rather than just putting a single array into the bootstrap
    code, as is done now. This will give people a consistent behavior.
    For example, I personally was confused for a bit after I did my build
    that script including a file didn't work - I never dojo.require files
    unless absolutely necessary, so it didn't even occur to me to do so.
    I'm sure a lot of other people will find the same problem.
    You got started before I could do the documentation. I still need to
    do a fix for the debugAtAllCosts case before I did the docs. So you
    got hit with some confusing parts of using the feature. I consider
    this a very "advanced" feature, so I think it is fine that it needs
    some explanation in the documentation.

    Also, using raw script tags and not using dojo.require means you are
    not using the loader in the "standard" way. You are free to do that if
    you know what you are doing, but it will be more work going outside
    that path. However, I'm not sure I should put in extra code to support
    this path for an advanced feature like multiple version support. I was
    able to introduce the feature easily by leveraging the work that
    dojo.require does.

    [snip]
    I'm trying to walk the line of not giving too many degrees of freedom,
    particularly as we get into further "fringe" use cases, like
    multiversion support, but still have the feature usable.
    Agreed. However in this case, with the existing build option we can
    make this work both with dojo.require and with script tags, with no
    extra complexity than already exists.
    I would not want this behavior (injecting the anonymous function
    wrapper in the source as part of a build) as a default part of the
    build because that means you have to know the new scope names *up
    front* when you do the build (see the bar, bijit and barx example
    above).

    The way it works now, there is no assumption on the scope names, and
    you can decide at runtime what they will be. I like that as a default
    because it means you can do a build without specifying any
    scope-related stuff and it will work.

    However, if you want to "burn in" scope names, then there is a build
    option for that. That is necessary to make sure you can provide your
    own library under your own namespace without needing your users to
    configure it.

    There are also build options for the xdomain case, because that one
    uses script tags to load things, and it needs to know the global names
    so it can register the loaded code correctly. It is unfortunate that
    you need these at all, and I tried to avoid it, but cannot given that
    scripts are loaded in the global scope.

    I'm just not seeing a good case to introduce another option for a use
    case that does not follow our standard use advice, mainly use
    dojo.require to load code. Particularly when, to get it to work in
    dev, you also have to do manual function trickery for it to work (the
    bar/bijit/barx example above).

    Also, I'm hoping that after I get the documentation finished, it will
    help some, and will have saved some of the frustration you encountered
    when first trying to use the feature.

    James
  • Bill Keese at Jan 25, 2008 at 8:03 pm

    On Jan 22, 2008 1:15 AM, Shane O'Sullivan wrote:
    I think the larger issue is why are you doing the script includes?
    Script includes should always be used in any high-traffic site. Since
    dojo.require calls are no browser cached
    Is that really true? I thought they were cached and that's why I have
    to keep hitting the "empty cache" button on IE whenever I change
    something. I guess on FF it reloads every time but I thought that was
    because my web server (which is unconfigured) doesn't put an expiration
    date on the js files.
  • Shane O'Sullivan at Jan 26, 2008 at 7:51 am
    Each browser behaved differently, as far as I know. I researched it a
    while ago, and Firefox at least didn't cache it, while IE cached too
    much. I haven't looked into it recently though, so perhaps the latest
    batch of browsers have fixed this.

    Shane
    On 26/01/2008, Bill Keese wrote:
    On Jan 22, 2008 1:15 AM, Shane O'Sullivan wrote:
    I think the larger issue is why are you doing the script includes?
    Script includes should always be used in any high-traffic site. Since
    dojo.require calls are no browser cached
    Is that really true? I thought they were cached and that's why I have
    to keep hitting the "empty cache" button on IE whenever I change
    something. I guess on FF it reloads every time but I thought that was
    because my web server (which is unconfigured) doesn't put an expiration
    date on the js files.
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Alex Russell at Jan 26, 2008 at 6:24 pm
    - -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    The non-caching behavior on FF changed from 1.5 to 2.0. For all
    intents and purposes, it's "fixed" now.

    Regards
    On Jan 26, 2008, at 4:51 AM, Shane O'Sullivan wrote:

    Each browser behaved differently, as far as I know. I researched it a
    while ago, and Firefox at least didn't cache it, while IE cached too
    much. I haven't looked into it recently though, so perhaps the latest
    batch of browsers have fixed this.
    - - --
    Alex Russell
    alex at sitepen.com A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
    alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

    - -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (Darwin)

    iD8DBQFHm8Ekz3jiQlnDlyMRAkykAJ4vIHDyezb1E0JaBz0dvrxnzt9olQCeN9s2
    Di+jz6fV6Uq8BD8N0JfsnHY£3G
    - -----END PGP SIGNATURE-----
  • Douglas Hays at Jan 26, 2008 at 8:41 pm
    This is a FYI for people who run tests using file:/// on Firefox.

    I was having a problem running the dijit unit tests using a file:/// URL
    after installing the latest Firefox 3 beta 2. It seems that the new
    Firefox
    is not going to allow local files to easily access other files in parent
    directories. I was able to get around this by setting a preference:

    security.fileuri.origin_policy = 3
    0=only this file is OK, 1=same dir is OK, 2=child dir is OK, 3=any file is
    OK

    The default was 2. It might be a security issue but I needed it to work
    until I figure out a
    better solution. If anyone knows of a better way, then I'd appreciate the
    info.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20080126/17115e65/attachment.htm

Related Discussions