I've been pondering the directory structure as it relates to downloading
from svn as well as from downloaded packages. After our meeting last
week, we basically were trying to accomplish:

1) keeping dojo-widget and dojo-ext inside of the dojo.namepaces
2) make them easy dropin add ons by default for downloaders
3) make them easy to use get all in svn by checking out a psuedo
repository with svn:externals pointing at the actual repository.

As we discussed at that meeting, here is an updated plan of attack just
in time for discussion (resolution?) at tomorrow's meeting :)

Currently we have something along the lines of:

dojo/
dojo.js
src/
resource.js
dir/
resource2.js


The files that we want to require are identified by
dojo.require("dojo.dir.resource2"); As you can see, we hack a little
level of indirection there to skip "src" so we have dojo.dir.resource2
instead of dojo.src.dir.resource2.

My question is what does this buy us? It seems like the only thing that
it has going for it is avoiding having as many files in the root directory.

My proposal is to flatten the dojo tree by a level, while at the same
time trying to move some of the files that are in the root to a
different location in the tree. As an example, something along the
lines of:

dojo/
dojo.js
bootstrap/
loader.js
bootstrap.js
html/
common.js
foo/
bar.js


other resources of course would be here too
docs/
TheDojoBook.pdf
util/
buildscripts/
docscripts/


Now of course we probalby can't get rid of all the "loose" files in the
the current src/ dir. However, where it is possible, we should. In my
opinion, getting rid of some files, in combination with fewer items
being included because of being relocated to dojo.ext, this makes this
level of indirection unneeded.

The widget package might look like (or could look like something else
underneath widget/):

widget/
Button.js (the actual widget)
Button/
default.css (if any)
template.html (if any)
images/
image.png (if any)
tests/
test.html
OtherWidget.js
OtherWidget/
default.css
images/
tests/
featureA.js <- mixin
featureB.js <- mixin

Note:
capability: dojo.uri.moduleUri("dojo.widget.Button", "default.css");


So back to the directory structure. Simply putting the widget directory
inside of the dojo directory will make it just "work"
(dojo.require("dojo.widget.Foo"); will resolve properly. If for some
reason (probably just to be difficult) you put the widget directory in
../path/foo/widget, and in that case you would have to do something like:

dojo.registerModulePath("dojo.widget", "../path/foo/widget");

note: this is an "advanced thing though, not the default

For the ext package, things are the same as they are now, but they
should be reworked to be inside of the dojo.ext namespace. Simply unpack
the ext package into the dojoRoot/ext directory.

If you download all three packages (or a package containing all of them)
you would end up with something like:

dojo/
README
LICENSE
dojo.js
bootstrap/
loader.js
bootstrap.js
widget/
README
LICENSE
Button.js
Button/
OtherWidget.js
OtherWidget/
ext/
README
LICENSE
crypto/
uui/

So, now that we have looked at the directory structure of the packages,
lets look from a svn perspective:

dojo/
toolkit/
trunk/
README
LICENSE
dojo.js
...rest of core
docs/
TheDojoBook.pdf
utils/
docs/
builds/
branches/
tags
widget/
trunk/
README
LICENSE
Button.js
Button/
default.css
...
branches/
tags/
ext/
trunk/
README
LICENSE
...

additional psuedo repository:

all/
trunk/
dojo/ <-- svn::external to /dojo/toolkit/trunk

dojo.js
...modules from core
widget <-- svn external to /dojo/widget/trunk
ext <-- svn external to /dojo/ext/trunk

branches/
tags/


So to sum this up, making this change will make it so the following happens:

1) Simply expanding the toolkit dir, and including dojo.js stays
the same
2) Expanding dojo-widget.tgz inside of dojoRoot will create a
widget directory with all the widgets in. No registry of the module is
required. including widgets stays as dojo.require("dojo.widget.Foo");
3) Expanding dojo-ext.tgz inside of dojoRoot will make all of the
dojo.ext stuff available. No module registration required.

Furthermore, Simply placing a directory and file inside of dojoRoot
make is available as dojo.require("dojo.foo.bar"). The convention is as
follows:

if dojo. look in dojoRoot/, else look in dojoRoot/../foo where foo.

Does this sound workable to everyone? I believe it keeps things simple.

Dustin

Search Discussions

  • Karl Tiedt at Jan 23, 2007 at 7:43 pm
    Sounds very reasonable. I like this idea, very neat and clean with minimal
    "getting used to" appeal to it.
    On 1/23/07, Dustin Machi wrote:

    I've been pondering the directory structure as it relates to downloading
    from svn as well as from downloaded packages. After our meeting last
    week, we basically were trying to accomplish:

    1) keeping dojo-widget and dojo-ext inside of the dojo.namepaces
    2) make them easy dropin add ons by default for downloaders
    3) make them easy to use get all in svn by checking out a psuedo
    repository with svn:externals pointing at the actual repository.

    As we discussed at that meeting, here is an updated plan of attack just
    in time for discussion (resolution?) at tomorrow's meeting :)

    Currently we have something along the lines of:

    dojo/
    dojo.js
    src/
    resource.js
    dir/
    resource2.js


    The files that we want to require are identified by
    dojo.require("dojo.dir.resource2"); As you can see, we hack a little
    level of indirection there to skip "src" so we have dojo.dir.resource2
    instead of dojo.src.dir.resource2.

    My question is what does this buy us? It seems like the only thing that
    it has going for it is avoiding having as many files in the root
    directory.

    My proposal is to flatten the dojo tree by a level, while at the same
    time trying to move some of the files that are in the root to a
    different location in the tree. As an example, something along the
    lines of:

    dojo/
    dojo.js
    bootstrap/
    loader.js
    bootstrap.js
    html/
    common.js
    foo/
    bar.js


    other resources of course would be here too
    docs/
    TheDojoBook.pdf
    util/
    buildscripts/
    docscripts/


    Now of course we probalby can't get rid of all the "loose" files in the
    the current src/ dir. However, where it is possible, we should. In my
    opinion, getting rid of some files, in combination with fewer items
    being included because of being relocated to dojo.ext, this makes this
    level of indirection unneeded.

    The widget package might look like (or could look like something else
    underneath widget/):

    widget/
    Button.js (the actual widget)
    Button/
    default.css (if any)
    template.html (if any)
    images/
    image.png (if any)
    tests/
    test.html
    OtherWidget.js
    OtherWidget/
    default.css
    images/
    tests/
    featureA.js <- mixin
    featureB.js <- mixin

    Note:
    capability: dojo.uri.moduleUri("dojo.widget.Button", "default.css");


    So back to the directory structure. Simply putting the widget directory
    inside of the dojo directory will make it just "work"
    (dojo.require("dojo.widget.Foo"); will resolve properly. If for some
    reason (probably just to be difficult) you put the widget directory in
    ../path/foo/widget, and in that case you would have to do something like:

    dojo.registerModulePath("dojo.widget", "../path/foo/widget");

    note: this is an "advanced thing though, not the default

    For the ext package, things are the same as they are now, but they
    should be reworked to be inside of the dojo.ext namespace. Simply unpack
    the ext package into the dojoRoot/ext directory.

    If you download all three packages (or a package containing all of them)
    you would end up with something like:

    dojo/
    README
    LICENSE
    dojo.js
    bootstrap/
    loader.js
    bootstrap.js
    widget/
    README
    LICENSE
    Button.js
    Button/
    OtherWidget.js
    OtherWidget/
    ext/
    README
    LICENSE
    crypto/
    uui/

    So, now that we have looked at the directory structure of the packages,
    lets look from a svn perspective:

    dojo/
    toolkit/
    trunk/
    README
    LICENSE
    dojo.js
    ...rest of core
    docs/
    TheDojoBook.pdf
    utils/
    docs/
    builds/
    branches/
    tags
    widget/
    trunk/
    README
    LICENSE
    Button.js
    Button/
    default.css
    ...
    branches/
    tags/
    ext/
    trunk/
    README
    LICENSE
    ...

    additional psuedo repository:

    all/
    trunk/
    dojo/ <-- svn::external to /dojo/toolkit/trunk

    dojo.js
    ...modules from core
    widget <-- svn external to /dojo/widget/trunk
    ext <-- svn external to /dojo/ext/trunk

    branches/
    tags/


    So to sum this up, making this change will make it so the following
    happens:

    1) Simply expanding the toolkit dir, and including dojo.js stays
    the same
    2) Expanding dojo-widget.tgz inside of dojoRoot will create a
    widget directory with all the widgets in. No registry of the module is
    required. including widgets stays as dojo.require("dojo.widget.Foo");
    3) Expanding dojo-ext.tgz inside of dojoRoot will make all of the
    dojo.ext stuff available. No module registration required.

    Furthermore, Simply placing a directory and file inside of dojoRoot
    make is available as dojo.require("dojo.foo.bar"). The convention is as
    follows:

    if dojo. look in dojoRoot/, else look in dojoRoot/../foo where foo.

    Does this sound workable to everyone? I believe it keeps things simple.

    Dustin
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors@dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors


    --
    -Karl Tiedt
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://dojotoolkit.org/pipermail/dojo-contributors/attachments/20070123/88afaa38/attachment.html
  • Adam L. Peller at Jan 23, 2007 at 8:07 pm
    comments inline
    On 1/23/07, Dustin Machi wrote:
    Currently we have something along the lines of:

    dojo/
    dojo.js
    src/
    resource.js
    dir/
    resource2.js
    Well, there's nothing that defines the top-level as being 'dojo'. I
    call mine 'trunk' or foo-branch or whatever.
    The files that we want to require are identified by
    dojo.require("dojo.dir.resource2"); As you can see, we hack a little
    level of indirection there to skip "src" so we have dojo.dir.resource2
    instead of dojo.src.dir.resource2.
    We're not skipping src; we're mapping src to dojo, and that's always
    been a source of confusion. I'd love to see this go away also, but in
    a different way...
    My question is what does this buy us? It seems like the only thing that
    it has going for it is avoiding having as many files in the root directory.
    I think we need a directory to identify the namespace root such that
    everything under it is exclusively namespaced js code. 'src' sort of
    served this purpose, but only for the 'dojo' namespace.
    My proposal is to flatten the dojo tree by a level, while at the same
    time trying to move some of the files that are in the root to a
    different location in the tree. As an example, something along the
    lines of:

    dojo/
    dojo.js
    bootstrap/
    loader.js
    bootstrap.js
    html/
    common.js
    foo/
    bar.js
    I like this, except:
    other resources of course would be here too
    docs/
    TheDojoBook.pdf
    util/
    buildscripts/
    docscripts/
    These aren't .js resources, and they live where dojo.docs or dojo.util
    ought to be. I find this misleading. Call me a purist.

    So, I'd really like to see a 'js' directory at the top-level with
    'dojo' underneath it, a peer with docs, utils, etc. (I'd argue that
    we call it something like 'js' instead of 'src', since there is no
    source to compile here) I know, for those of you who choose to call
    your top-level directory 'dojo', that's going to look confusing:
    dojo/js/dojo/lang/... But it's a logical and flexible directory
    structure, and that one directory isn't much of a burden, IMO. We can
    instruct people to use an svn command like svn co ... dtk Then you
    have dtk/js/dojo/lang...

    So we only have a dojo namespace in this project by convention. That
    may or may not be the case going forward. And if we structure things
    this way, presumably it will be easier to overlay other projects with
    other namespaces directly.

    -Adam
  • Dustin Machi at Jan 23, 2007 at 8:48 pm

    Adam L. Peller wrote:
    comments inline
    On 1/23/07, Dustin Machi wrote:
    Currently we have something along the lines of:

    dojo/
    dojo.js
    src/
    resource.js
    dir/
    resource2.js
    Well, there's nothing that defines the top-level as being 'dojo'. I
    call mine 'trunk' or foo-branch or whatever.
    Of course, i call mine dojo-trunk myself.
    The files that we want to require are identified by
    dojo.require("dojo.dir.resource2"); As you can see, we hack a little
    level of indirection there to skip "src" so we have dojo.dir.resource2
    instead of dojo.src.dir.resource2.
    We're not skipping src; we're mapping src to dojo, and that's always
    been a source of confusion. I'd love to see this go away also, but in
    a different way...
    True, but I do see it as skipping source. Assuming "dojo" map
    automatically to where dojo.js is. Without any additional work,
    everythign falls neatly underneath.
    My question is what does this buy us? It seems like the only thing that
    it has going for it is avoiding having as many files in the root
    directory.
    I think we need a directory to identify the namespace root such that
    everything under it is exclusively namespaced js code. 'src' sort of
    served this purpose, but only for the 'dojo' namespace.
    so i'm fine with that if dojo.js moves down with it, but anything other
    than that providing a level of indirection. Something like this might work:

    [dojo root]/
    README
    LICENSE
    docs/
    util/
    lib/
    dojo.js
    /bootstrap/
    loader.js
    ...
    widget/
    ext/


    The disadvantage of this approach is that you include
    "dojoRoot/lib/dojo.js" and if you have a third party thing we need to
    look for ../../namespace by default which is kind of nasty to me.
    I like this, except:
    other resources of course would be here too
    docs/
    TheDojoBook.pdf
    util/
    buildscripts/
    docscripts/
    These aren't .js resources, and they live where dojo.docs or dojo.util
    ought to be. I find this misleading. Call me a purist.
    neither are css or html, resources are just data. I agree it is
    annoying though. However, to me it is worth it.

    So, I'd really like to see a 'js' directory at the top-level with
    'dojo' underneath it, a peer with docs, utils, etc. (I'd argue that
    we call it something like 'js' instead of 'src', since there is no
    source to compile here) I know, for those of you who choose to call
    your top-level directory 'dojo', that's going to look confusing:
    dojo/js/dojo/lang/... But it's a logical and flexible directory
    structure, and that one directory isn't much of a burden, IMO. We can
    instruct people to use an svn command like svn co ... dtk Then you
    have dtk/js/dojo/lang...
    So the directory doesn't come in to play as far as I know, dojo comes
    from where "dojo.js" is and so all dojo sit beneath it. Something like this:
    dojoRoot/
    js/
    dojo/
    dojo.js
    module/
    module.js

    This is essentially the same thing with an empty dir at the top. It
    seems since that directory may or may not be omitted, then the defaul of
    looking to ../../namespace for external namespaces woudl be more fragile
    than, ../ .

    Dustin
  • Adam L. Peller at Jan 24, 2007 at 12:25 pm
    I think I'm with you on everything except for dojo.js -- dojo.js isn't
    namespaced. It's not part of the packaging system. And it's
    bootstrap for the bootstrap. Why can't it live anywhere we want, like
    the top-level directory, for convenience? As you suggest,
    convenience, for that one file, is important.

    -Adam
    On 1/23/07, Dustin Machi wrote:


    Adam L. Peller wrote:
    comments inline
    On 1/23/07, Dustin Machi wrote:
    Currently we have something along the lines of:

    dojo/
    dojo.js
    src/
    resource.js
    dir/
    resource2.js
    Well, there's nothing that defines the top-level as being 'dojo'. I
    call mine 'trunk' or foo-branch or whatever.
    Of course, i call mine dojo-trunk myself.
    The files that we want to require are identified by
    dojo.require("dojo.dir.resource2"); As you can see, we hack a little
    level of indirection there to skip "src" so we have dojo.dir.resource2
    instead of dojo.src.dir.resource2.
    We're not skipping src; we're mapping src to dojo, and that's always
    been a source of confusion. I'd love to see this go away also, but in
    a different way...
    True, but I do see it as skipping source. Assuming "dojo" map
    automatically to where dojo.js is. Without any additional work,
    everythign falls neatly underneath.
    My question is what does this buy us? It seems like the only thing that
    it has going for it is avoiding having as many files in the root
    directory.
    I think we need a directory to identify the namespace root such that
    everything under it is exclusively namespaced js code. 'src' sort of
    served this purpose, but only for the 'dojo' namespace.
    so i'm fine with that if dojo.js moves down with it, but anything other
    than that providing a level of indirection. Something like this might work:

    [dojo root]/
    README
    LICENSE
    docs/
    util/
    lib/
    dojo.js
    /bootstrap/
    loader.js
    ...
    widget/
    ext/


    The disadvantage of this approach is that you include
    "dojoRoot/lib/dojo.js" and if you have a third party thing we need to
    look for ../../namespace by default which is kind of nasty to me.
    I like this, except:
    other resources of course would be here too
    docs/
    TheDojoBook.pdf
    util/
    buildscripts/
    docscripts/
    These aren't .js resources, and they live where dojo.docs or dojo.util
    ought to be. I find this misleading. Call me a purist.
    neither are css or html, resources are just data. I agree it is
    annoying though. However, to me it is worth it.

    So, I'd really like to see a 'js' directory at the top-level with
    'dojo' underneath it, a peer with docs, utils, etc. (I'd argue that
    we call it something like 'js' instead of 'src', since there is no
    source to compile here) I know, for those of you who choose to call
    your top-level directory 'dojo', that's going to look confusing:
    dojo/js/dojo/lang/... But it's a logical and flexible directory
    structure, and that one directory isn't much of a burden, IMO. We can
    instruct people to use an svn command like svn co ... dtk Then you
    have dtk/js/dojo/lang...
    So the directory doesn't come in to play as far as I know, dojo comes
    from where "dojo.js" is and so all dojo sit beneath it. Something like this:
    dojoRoot/
    js/
    dojo/
    dojo.js
    module/
    module.js

    This is essentially the same thing with an empty dir at the top. It
    seems since that directory may or may not be omitted, then the defaul of
    looking to ../../namespace for external namespaces woudl be more fragile
    than, ../ .

    Dustin







    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors@dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Dustin Machi at Jan 24, 2007 at 12:33 pm

    Adam L. Peller wrote:
    I think I'm with you on everything except for dojo.js -- dojo.js isn't
    namespaced. It's not part of the packaging system. And it's
    bootstrap for the bootstrap. Why can't it live anywhere we want, like
    the top-level directory, for convenience? As you suggest,
    convenience, for that one file, is important.
    My point is that without redirection of some sort, everthing is relative
    to this bootstrap file, regardless of what it is called. Currently we
    expect everthing dojo to live in src/ from that file and everything
    outside to live ../ from it.

    Dustin
  • Bill Keese at Jan 24, 2007 at 1:43 am

    Dustin Machi wrote:
    1) keeping dojo-widget and dojo-ext inside of the dojo.namepaces
    2) make them easy dropin add ons by default for downloaders
    3) make them easy to use get all in svn by checking out a psuedo
    repository with svn:externals pointing at the actual repository.

    ...
    So back to the directory structure. Simply putting the widget directory
    inside of the dojo directory will make it just "work"
    (dojo.require("dojo.widget.Foo"); will resolve properly.

    For me, putting widgets (and ext) inside the "dojo" directory is asking
    for trouble. I know that keeping the namespace as "dojo.widget" is
    desirable, but I don't think it's worth it. It just seems too
    confusing to tell people to download core and widgets, and then put
    widgets inside of core. (if they re-download core, to get a patch or
    something, it will erase the widgets)

    I see them as peers like:

    dojo/
    dojo_widget/
    dojo_ext/

    I think we could modify dojo such that if you see a

    dojo.require("ajax.foo")

    but there's been no registerModulePath() call, we should probably just
    assume the path is "../ajax". (Maybe it does that already)
  • Tom Trenka at Jan 24, 2007 at 10:13 am
    I'm with Bill on this one; I think we should be defining the other two
    projects as external modules, just like any other external modules--and we
    should probably start thinking about real names for them. I'm actually OK
    with "dojox" but I think I'd prefer something more than "dojowidget"--at
    least from a marketing standpoint.

    Perhaps "Shiny Marbles" :)

    trt
    On 1/24/07, Bill Keese wrote:

    Dustin Machi wrote:
    1) keeping dojo-widget and dojo-ext inside of the dojo.namepaces
    2) make them easy dropin add ons by default for downloaders
    3) make them easy to use get all in svn by checking out a psuedo
    repository with svn:externals pointing at the actual repository.

    ...
    So back to the directory structure. Simply putting the widget directory
    inside of the dojo directory will make it just "work"
    (dojo.require("dojo.widget.Foo"); will resolve properly.

    For me, putting widgets (and ext) inside the "dojo" directory is asking
    for trouble. I know that keeping the namespace as "dojo.widget" is
    desirable, but I don't think it's worth it. It just seems too
    confusing to tell people to download core and widgets, and then put
    widgets inside of core. (if they re-download core, to get a patch or
    something, it will erase the widgets)

    I see them as peers like:

    dojo/
    dojo_widget/
    dojo_ext/

    I think we could modify dojo such that if you see a

    dojo.require("ajax.foo")

    but there's been no registerModulePath() call, we should probably just
    assume the path is "../ajax". (Maybe it does that already)


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors@dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://dojotoolkit.org/pipermail/dojo-contributors/attachments/20070124/f978dcff/attachment-0001.html
  • Scott J. Miles at Jan 24, 2007 at 10:33 am
    An important goal that Dustin achieved was elimination of indirections that
    become the burden of user's JS code. IMO, requiring our source structure to
    be 'normalized' by our applications is putting the burden in the wrong
    place.

    However, I see Bill's point as well.

    If I understand you correctly Tom, you are saying that (1) we put the
    modules as peers to the core and (2) we give them their own top level names.
    I don't love losing the primacy of "dojo." but this will solve the
    indirection problem.

    ("Shiny Marbles" can be our jingle, sung to the tune of "Tiny Bubbles")

    I also understand the downside of mixing up source and tools. It's going to
    be hard to serve all masters. I suppose that if we do go with a
    peer-structure, 'tools' (and/or 'docs') could be a separate entity as well.

    Example (actual names likely to be different):

    <toolkit>/
    dojo/ -> core
    dojow/ -> widgets
    dojox/ -> ext
    tools/
    docs/

    Here I am suggesting that
    "dojo.foo" => <toolkit>/dojo/foo.js
    "dojow.foo" => <toolkit>/dojow/foo.js
    and so on

    Regards,
    Scott J. Miles
    TurboAjax Group
    http://www.turboajax.com




    _____

    From: dojo-contributors-bounces@dojotoolkit.org
    On Behalf Of Tom Trenka
    Sent: Wednesday, January 24, 2007 9:14 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Directory/Package/Svn Structure
    continueddiscussion...


    I'm with Bill on this one; I think we should be defining the other two
    projects as external modules, just like any other external modules--and we
    should probably start thinking about real names for them. I'm actually OK
    with "dojox" but I think I'd prefer something more than "dojowidget"--at
    least from a marketing standpoint.

    Perhaps "Shiny Marbles" :)

    trt


    On 1/24/07, Bill Keese <HYPERLINK
    "mailto:bill@dojotoolkit.org"bill@dojotoolkit.org> wrote:

    Dustin Machi wrote:
    1) keeping dojo-widget and dojo-ext inside of the dojo.namepaces
    2) make them easy dropin add ons by default for downloaders
    3) make them easy to use get all in svn by checking out a psuedo
    repository with svn:externals pointing at the actual repository.

    ...
    So back to the directory structure. Simply putting the widget directory
    inside of the dojo directory will make it just "work"
    (dojo.require("dojo.widget.Foo"); will resolve properly.

    For me, putting widgets (and ext) inside the "dojo" directory is asking
    for trouble. I know that keeping the namespace as "dojo.widget" is
    desirable, but I don't think it's worth it. It just seems too
    confusing to tell people to download core and widgets, and then put
    widgets inside of core. (if they re-download core, to get a patch or
    something, it will erase the widgets)

    I see them as peers like:

    dojo/
    dojo_widget/
    dojo_ext/

    I think we could modify dojo such that if you see a

    dojo.require("ajax.foo")

    but there's been no registerModulePath() call, we should probably just
    assume the path is "../ajax". (Maybe it does that already)


    _______________________________________________
    dojo-contributors mailing list
    HYPERLINK
    "mailto:dojo-contributors@dojotoolkit.org"dojo-contributors@dojotoolkit.org
    HYPERLINK
    "http://dojotoolkit.org/mailman/listinfo/dojo-contributors"http://dojotoolki
    t.org/mailman/listinfo/dojo-contributors




    --
    No virus found in this incoming message.
    Checked by AVG Free Edition.
    Version: 7.5.432 / Virus Database: 268.17.8/649 - Release Date: 1/23/2007
    8:40 PM





    --
    No virus found in this outgoing message.
    Checked by AVG Free Edition.
    Version: 7.5.432 / Virus Database: 268.17.8/649 - Release Date: 1/23/2007
    8:40 PM

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://dojotoolkit.org/pipermail/dojo-contributors/attachments/20070124/909e5797/attachment.html
  • Tom Trenka at Jan 24, 2007 at 10:45 am

    On 1/24/07, Scott J. Miles wrote:

    If I understand you correctly Tom, you are saying that (1) we put the
    modules as peers to the core and (2) we give them their own top level names.
    I don't love losing the primacy of "dojo." but this will solve the
    indirection problem.
    Yes, that's what I'm suggesting. It also has the auxiliary benefit of
    showing others how to properly implement external modules, which to date has
    been a little spotty.

    ("Shiny Marbles" can be our jingle, sung to the tune of "Tiny Bubbles")
    >

    I was kidding about Shiny Marbles; it was a dig at Dylan, who once suggested
    it when we were trying to come up with the name "Dojo" :)

    I also understand the downside of mixing up source and tools. It's going to
    be hard to serve all masters. I suppose that if we do go with a
    peer-structure, 'tools' (and/or 'docs') could be a separate entity as well.

    Example (actual names likely to be different):

    <toolkit>/
    dojo/ -> core
    dojow/ -> widgets
    dojox/ -> ext
    tools/
    docs/
    I completely concur with this as well; it was one of the reasons I suggested
    that we split out both the build system and the doc system in addition to
    widgets and dojox at last week's IRC meeting. (I think that's when I
    suggested it).

    trt
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://dojotoolkit.org/pipermail/dojo-contributors/attachments/20070124/5bacdc6e/attachment.html
  • Owen Williams at Jan 24, 2007 at 10:58 am
    On Jan 24, 2007, at 9:33 AM, Scott J. Miles wrote:

    This seems like a clear win for including other top-level modules as
    well, eg:
    <toolkit>/
    dojo/ -> core
    dojow/ -> widgets
    dojox/ -> ext
    tools/
    docs/
    turboAjax/
    myApp1/
    myApp2/

    Nice and clear, especially if we get the default namespace mapping to
    follow this as well.

    But, please, whatever we end up with, make sure I can can just go to
    the "toolkit" directory above and do a single "svn up" to update all
    the various source directories at once. This may seem like a small
    thing, but I've chased my tail a number of times trying to figure out
    why code I'd written didn't work, and it was because I forgot to "up"
    one project or another. Let's not make our marketing-based
    reorganization make the code harder to use day to day.

    cheers
    O

    -------------------------
    We must be the change we wish to see in the world. -- Mohandas K.
    Gandhi



    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://dojotoolkit.org/pipermail/dojo-contributors/attachments/20070124/134e579b/attachment.html
  • James Burke at Jan 24, 2007 at 11:37 am

    On 1/24/07, Scott J. Miles wrote:
    Example (actual names likely to be different):

    <toolkit>/
    dojo/ -> core
    dojow/ -> widgets
    dojox/ -> ext
    tools/
    docs/
    Where is dojo.js located in a custom build scenario,
    <toolkit>/dojo/dojo.js or <toolkit>/dojo.js? I can see where
    <toolkit>/dojo.js makes sense because dojo.js might include modules
    from the other directories. However, I'm not sure how that looks in
    svn for the non-custom build case (using the simple bootstrap loader
    that exists by default in svn).

    I would prefer <toolkit>/dojo.js from a build perspective, since
    dojo.js can include modules from the other directories, and I'll be
    changing the build process to modify files in the other module
    directories, if they are listed as part of the dependencies.prefixes
    array. Modifications include flattening resource bundles, inlining
    templates, and probably comments/extra white space removal.

    Since there will be code modification, it makes sense to copy the
    sources in dojow, dojox, etc... to something like a "release"
    directory. In that scenario, having the release directory act like a
    <toolkit> directory as specified above, and having <toolkit>/dojo.js
    seems logical. But again, I'm not sure what that means for the
    non-build dojo.js case in svn.

    James
  • Scott J. Miles at Jan 24, 2007 at 12:17 pm
    This is a hard problem and I don't have a clear opinion on what solution is
    best. =But for the sake of clarity:

    Under the proposed structure, I believe the default dojo.js (svn) lives in

    <some root>/
    dojo/dojo.js
    Where is dojo.js located in a custom build
    scenario,<toolkit>/dojo/dojo.js or <toolkit>/dojo.js?

    I'm not quite sure what you mean by "a custom build scenario", since there
    are many such things. If I build everything I need into dojo.js, then I can
    put it absolutely anywhere. Assuming you want dynamic access to other
    source, I believe it would look like so:

    <some root>/
    dojo/dojo.js
    dojo/<needed source>
    <other top level thing>/<needed source>
    <another top level thing>/<needed source>

    Of course, actual placement of the files is currently controllable to a
    significant degree by registerModulePath, but I think we are trying to
    discourage that kind of path magic whenever possible.

    Hope I didn't miss entirely the point of your mail. :)

    Regards,
    Scott J. Miles
    TurboAjax Group
    http://www.turboajax.com

    -----Original Message-----
    From: dojo-contributors-bounces@dojotoolkit.org
    On Behalf
    Of James Burke
    Sent: Wednesday, January 24, 2007 10:37 AM
    To: dojo dev.
    Subject: Re: [dojo-contributors] Directory/Package/Svn
    Structurecontinueddiscussion...
    On 1/24/07, Scott J. Miles wrote:
    Example (actual names likely to be different):

    <toolkit>/
    dojo/ -> core
    dojow/ -> widgets
    dojox/ -> ext
    tools/
    docs/
    Where is dojo.js located in a custom build scenario,
    <toolkit>/dojo/dojo.js or <toolkit>/dojo.js? I can see where
    <toolkit>/dojo.js makes sense because dojo.js might include
    modules from the other directories. However, I'm not sure how
    that looks in svn for the non-custom build case (using the
    simple bootstrap loader that exists by default in svn).

    I would prefer <toolkit>/dojo.js from a build perspective,
    since dojo.js can include modules from the other directories,
    and I'll be changing the build process to modify files in the
    other module directories, if they are listed as part of the
    dependencies.prefixes array. Modifications include flattening
    resource bundles, inlining templates, and probably
    comments/extra white space removal.

    Since there will be code modification, it makes sense to copy
    the sources in dojow, dojox, etc... to something like a "release"
    directory. In that scenario, having the release directory act
    like a <toolkit> directory as specified above, and having
    <toolkit>/dojo.js seems logical. But again, I'm not sure what
    that means for the non-build dojo.js case in svn.

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors@dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
    --
    No virus found in this outgoing message.
    Checked by AVG Free Edition.
    Version: 7.5.432 / Virus Database: 268.17.8/649 - Release Date: 1/23/2007
    8:40 PM
  • Robert Coup at Jan 24, 2007 at 3:07 pm

    Scott J. Miles wrote:
    Where is dojo.js located in a custom build
    scenario,<toolkit>/dojo/dojo.js or <toolkit>/dojo.js?
    I'm not quite sure what you mean by "a custom build scenario", since there
    are many such things. If I build everything I need into dojo.js, then I can
    put it absolutely anywhere. Assuming you want dynamic access to other
    source, I believe it would look like so:

    <some root>/
    dojo/dojo.js
    dojo/<needed source>
    <other top level thing>/<needed source>
    <another top level thing>/<needed source>
    This makes sense to me. It allows people to structure their own SVN
    repositories like below and not have a pesky dojo.js floating around in
    the project directory which will get isolated from changes to the
    externals link to Core.

    project/
    dojo/ -> svn:externals - svn.dojotoolkit.org/core/tags/1.0/
    dojow/ -> svn:externals - svn.dojotoolkit.org/widgets/tags/1.0/
    dojox/ -> svn:externals - svn.dojotoolkit.org/extras/tags/1.0/
    myns/
    ... lots of stuff in here ...
    myotherns/
    .. more stuff ...

    Rob :)

    --
    One Track Mind Ltd.
    PO Box 1604, Shortland St, Auckland, New Zealand
    Phone +64-9-966 0433 Mobile +64-21-572 632
    Web http://www.onetrackmind.co.nz
  • Bill Keese at Jan 24, 2007 at 2:48 pm

    Scott J. Miles wrote:
    Example (actual names likely to be different):

    <toolkit>/
    dojo/ -> core
    dojow/ -> widgets
    dojox/ -> ext
    tools/
    docs/
    Well if four of us are thinking the same thing it must have some merit.
    Of course, this implies that you include widgets via:

    dojo.require("dojow.Button");

    and the module name is also dojow (or whatever we decide), like:

    new dojow.Button(...)

    By the way, My previous mail was probably unclear. I wanted to stress
    that dojo.require("dojow.Button") should (will) work without a
    registerModule() call, because the default will be to assume that module
    dojow (or any module) is in ../


    Tom Trenka:
    I was kidding about Shiny Marbles; it was a dig at Dylan, who once
    suggested it when we were trying to come up with the name "Dojo" :)

    Hmm, I was gonna suggest the same name but now that you say it's a JOKE,
    I feel kind of foolish ... :-)
  • Brian Douglas Skinner at Jan 24, 2007 at 3:42 pm

    Example (actual names likely to be different):

    <toolkit>/
    dojo/ -> core
    dojow/ -> widgets
    dojox/ -> ext
    tools/
    docs/
    Well if four of us are thinking the same thing it must have some merit.
    Of course, this implies that you include widgets via:

    dojo.require("dojow.Button");

    and the module name is also dojow (or whatever we decide), like:

    new dojow.Button(...)
    If you're looking for naming ideas, you might consider dojoui or dojoUI
    or dojo_ui as an alternative to dojow, especially if the dojow package
    will end up containing non-widget UI code. But maybe dojoui is just as
    cryptic as dojow, and dojoUI actually violates the dojo capitalization
    conventions.

    The example above uses the name "ext" for the dojox code, probably
    because "extensions" is way too long. If "extensions" is too long and
    "ext" is too cryptic, maybe "extras" would be a good compromise?

    :o) Brian

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedJan 23, '07 at 7:28p
activeJan 24, '07 at 3:42p
posts16
users10
websitedojotoolkit.org

People

Translate

site design / logo © 2022 Grokbase