Howdy all, just wanted to touch base on a few things:

There is a requirejs 2.0 release, and it supports to config values
that may be of interest for dojo, particularly since Rawld was
instrumental in their construction. If you see issues with them,
please feel free to let me know so we can improve it.

module config
====
Details here, but it allows passing config data to a module via module.config():
https://github.com/jrburke/requirejs/wiki/Upgrading-to-RequireJS-2.0#wiki-moduleconfig

map config:
====
This is based off of Dojo's packageMap capability, but basically a way
to alias dependencies to another module ID:
https://github.com/jrburke/requirejs/wiki/Upgrading-to-RequireJS-2.0#wiki-mapconfig

It is different from packageMap in that it works on any module ID, and
there is a "*" config that matches all module IDs, with a more precise
module ID prefix config taking precedence.

---

And on to something else, this may not be so useful, so feel free to ignore it:

Dojo 2.0 construction
====

I have started to use github's group capability to organize a set of
modules into a larger cohesive whole, but still giving them enough
individual space to have their own identity. I am doing that with the
requirejs plugins that I used to have in the requirejs repo:

https://github.com/requirejs

A similar approach for Dojo may make sense, and for dijit (by grouping
widgets under a "dijit" group name). Have a github.com/dojo/array,
github.com/dojo/Observable, etc... This may help people consume just
parts of Dojo without needing to get the full download today, and help
with the "dojo is too big" perception. It might also help identify
areas where there is too much interdependence.

A couple folks at work are using volo[1] to pull down JS
dependencies/manage internal dependencies, and I expect to have
recursive dependency fetching in the 0.2 release. But something like
that kind of tool or cpm that can read dependencies from the
package.json directly from github makes it easy to get just the code
needed for a project.

It would be interesting to just pull down Observable, the pub/sub
stuff and a dijit core to see how that would work for a light mvc
approach.

I know there are lots of forces in play for Dojo, so this may not make
sense. Just mentioning something that seems to be working for some
things.

[1] https://github.com/volojs/volo

James

Search Discussions

  • Dylan Schiemann at May 31, 2012 at 12:20 pm
    Thanks James.

    I assume Rawld and others will look through the module and map config
    details.

    And thanks for the suggestions around GitHub. We've been having similar
    discussions and thoughts through the various weekly meetings. I've added
    your suggestions to our ticket for planning how we use GitHub for 2.0 (
    http://plan.dojotoolkit.org/issues/64 )

    Regards,
    - -Dylan

    on 5/30/12 4:02 PM (GMT-07:00) James Burke said the following:
    Howdy all, just wanted to touch base on a few things:

    There is a requirejs 2.0 release, and it supports to config values
    that may be of interest for dojo, particularly since Rawld was
    instrumental in their construction. If you see issues with them,
    please feel free to let me know so we can improve it.

    module config
    ===> Details here, but it allows passing config data to a module via module.config():
    https://github.com/jrburke/requirejs/wiki/Upgrading-to-RequireJS-2.0#wiki-moduleconfig

    map config:
    ===> This is based off of Dojo's packageMap capability, but basically a way
    to alias dependencies to another module ID:
    https://github.com/jrburke/requirejs/wiki/Upgrading-to-RequireJS-2.0#wiki-mapconfig

    It is different from packageMap in that it works on any module ID, and
    there is a "*" config that matches all module IDs, with a more precise
    module ID prefix config taking precedence.

    ---

    And on to something else, this may not be so useful, so feel free to ignore it:

    Dojo 2.0 construction
    ===>
    I have started to use github's group capability to organize a set of
    modules into a larger cohesive whole, but still giving them enough
    individual space to have their own identity. I am doing that with the
    requirejs plugins that I used to have in the requirejs repo:

    https://github.com/requirejs

    A similar approach for Dojo may make sense, and for dijit (by grouping
    widgets under a "dijit" group name). Have a github.com/dojo/array,
    github.com/dojo/Observable, etc... This may help people consume just
    parts of Dojo without needing to get the full download today, and help
    with the "dojo is too big" perception. It might also help identify
    areas where there is too much interdependence.

    A couple folks at work are using volo[1] to pull down JS
    dependencies/manage internal dependencies, and I expect to have
    recursive dependency fetching in the 0.2 release. But something like
    that kind of tool or cpm that can read dependencies from the
    package.json directly from github makes it easy to get just the code
    needed for a project.

    It would be interesting to just pull down Observable, the pub/sub
    stuff and a dijit core to see how that would work for a light mvc
    approach.

    I know there are lots of forces in play for Dojo, so this may not make
    sense. Just mentioning something that seems to be working for some
    things.

    [1] https://github.com/volojs/volo

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedMay 30, '12 at 7:02p
activeMay 31, '12 at 12:20p
posts2
users2
websitedojotoolkit.org

2 users in discussion

James Burke: 1 post Dylan Schiemann: 1 post

People

Translate

site design / logo © 2021 Grokbase