In 1.6 (and earlier), requiring most dijit widgets would pull in the parser
and all of dijit/_base. With the 1.7 push to make granular dependencies, I
removed the parser dependency from most widgets. In addition, I'm thinking
about making the dijit/_base dependency list more granular (same as we are
doing for dojo/_base), in particular to avoid loading the popup and focus
code (~1000 lines). The upside is smaller code size, the downside is that
apps / custom widgets will have to add in dependencies that they are
missing. How do people feel about this?

The other question is about widgets themselves. In 2008 Alex made a
separate file for each (non-private) widget, but until 1.7 files like
ComboButton.js were just stubs that pointed back to Button.js. I finished
splitting up the widget definitions into separate files. This was so apps
could avoid pulling in widgets they weren't using, although again the
downside is that apps may need to add additional dojo.require() calls.
Opinions on this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110521/5b824318/attachment.htm

Search Discussions

  • Kenneth G. Franqueiro at May 21, 2011 at 1:47 am
    Personally I've been behind you on the "needing to specifically require
    dojo.parser is not a bug/regression" front, though I can easily concede
    that many people don't follow the practice of requiring it explicitly
    (and it's possible that our examples even don't). Based on the
    confusion we've already seen, it's certainly something that should be
    release noted to remind people.

    Nonetheless, the bottom line is it was never guaranteed to work, and
    there were instances before 1.7 where it wouldn't. There just happen to
    be more instances now.


    As for splitting up of other widgets, I think I'd personally be ok as
    long as we have a rather clearly marked section in release notes
    enumerating widgets that used to be defined within others' modules but
    now aren't. However, I seem to recall some of those "stubs" previously
    having "TODO: 2.0" type notes. I realize that modularization is
    important, especially for mobile, but are we jumping the gun too much on
    this?

    Since my history within the contributor circle is relatively shallow, my
    main question would be, historically, how much has DTK been willing to
    "break" things so long as they're documented in release notes? (I seem
    to recall 1.5 having a number of CSS selector changes release noted, for
    example, and I know a number of widget templates changed somewhere
    between 1.3 and 1.5.)

    "Breaking" things never looks good to the outside, no matter how noble
    the cause or how trivial the fix. How concerned should we be from a
    marketing perspective?

    --Ken
    On 5/21/2011 12:50 AM, Bill Keese wrote:
    In 1.6 (and earlier), requiring most dijit widgets would pull in the
    parser and all of dijit/_base. With the 1.7 push to make granular
    dependencies, I removed the parser dependency from most widgets. In
    addition, I'm thinking about making the dijit/_base dependency list more
    granular (same as we are doing for dojo/_base), in particular to avoid
    loading the popup and focus code (~1000 lines). The upside is smaller
    code size, the downside is that apps / custom widgets will have to add
    in dependencies that they are missing. How do people feel about this?

    The other question is about widgets themselves. In 2008 Alex made a
    separate file for each (non-private) widget, but until 1.7 files like
    ComboButton.js were just stubs that pointed back to Button.js. I
    finished splitting up the widget definitions into separate files. This
    was so apps could avoid pulling in widgets they weren't using, although
    again the downside is that apps may need to add additional
    dojo.require() calls. Opinions on this?



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Chris Mitchell at May 21, 2011 at 1:15 pm
    On the dojo.parser issue, it's true it was documented as strongly
    recommending to include dojo.parser, but then we gave customers
    examples that didn't. Like it or not, there are a lot of apps out
    there that will stop working because of this, whether it was intended
    or not because customers took our bad examples that didn't follow our
    own guidance and based their own code on them (the defects already
    reported by our own contributors are proof that this is just the tip
    of the iceberg) and if we can't fix this in a way that keeps there
    apps running without changes, we should be prepared to help them with
    this (docs, migration script, etc.) to minimize the costs to them.

    As far as the widget dependency refactors, we should be very concerned
    about breaking existing customers in 1.x stream, especially with 2.0
    just on the horizon. We have many, many large customers that will
    view having to make changes to their existing app's requires like this
    as regressions when their apps start breaking and they have to spend $
    figuring out how to fix all the places they're broken. If it's
    possible to keep apps running in 1.x, vs. making the pure technically
    correct call of modularizing, we should keep apps running. Keep a
    ticket open to fix the modularization for 2.x where customers will
    expect breakages like this, but minimize breaking current customers
    wherever we can.

    -Chris

    On Sat, May 21, 2011 at 1:47 AM, Kenneth G. Franqueiro
    wrote:
    Personally I've been behind you on the "needing to specifically require
    dojo.parser is not a bug/regression" front, though I can easily concede
    that many people don't follow the practice of requiring it explicitly
    (and it's possible that our examples even don't). ?Based on the
    confusion we've already seen, it's certainly something that should be
    release noted to remind people.

    Nonetheless, the bottom line is it was never guaranteed to work, and
    there were instances before 1.7 where it wouldn't. ?There just happen to
    be more instances now.


    As for splitting up of other widgets, I think I'd personally be ok as
    long as we have a rather clearly marked section in release notes
    enumerating widgets that used to be defined within others' modules but
    now aren't. ?However, I seem to recall some of those "stubs" previously
    having "TODO: 2.0" type notes. ?I realize that modularization is
    important, especially for mobile, but are we jumping the gun too much on
    this?

    Since my history within the contributor circle is relatively shallow, my
    main question would be, historically, how much has DTK been willing to
    "break" things so long as they're documented in release notes? ?(I seem
    to recall 1.5 having a number of CSS selector changes release noted, for
    example, and I know a number of widget templates changed somewhere
    between 1.3 and 1.5.)

    "Breaking" things never looks good to the outside, no matter how noble
    the cause or how trivial the fix. ?How concerned should we be from a
    marketing perspective?

    --Ken
    On 5/21/2011 12:50 AM, Bill Keese wrote:
    In 1.6 (and earlier), requiring most dijit widgets would pull in the
    parser and all of dijit/_base. ? With the 1.7 push to make granular
    dependencies, I removed the parser dependency from most widgets. ?In
    addition, I'm thinking about making the dijit/_base dependency list more
    granular (same as we are doing for dojo/_base), in particular to avoid
    loading the popup and focus code (~1000 lines). ? ?The upside is smaller
    code size, the downside is that apps / custom widgets will have to add
    in dependencies that they are missing. How do people feel about this?

    The other question is about widgets themselves. ? ?In 2008 Alex made a
    separate file for each (non-private) widget, but until 1.7 files like
    ComboButton.js were just stubs that pointed back to Button.js. ? I
    finished splitting up the widget definitions into separate files. ? This
    was so apps could avoid pulling in widgets they weren't using, although
    again the downside is that apps may need to add additional
    dojo.require() calls. ? Opinions on this?



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bill Keese at May 23, 2011 at 3:19 am

    On Sat, May 21, 2011 at 2:47 PM, Kenneth G. Franqueiro wrote:


    historically, how much has DTK been willing to
    "break" things so long as they're documented in release notes? (I seem
    to recall 1.5 having a number of CSS selector changes release noted, for
    example, and I know a number of widget templates changed somewhere
    between 1.3 and 1.5.)
    That's right, dijit typically has needed to make big changes like you
    mentioned, skirting the edge of backwards-compatibility. The dependency
    changes in 1.6 are minor compared to those other changes, although the
    downside is that they will affect more people.


    "Breaking" things never looks good to the outside, no matter how noble
    the cause or how trivial the fix. How concerned should we be from a
    marketing perspective?
    I think the marketing argument can go both ways. Certainly people could
    complain that they need to add in missing requires, but OTOH a lot of work
    for 1.7 has been in footprint reduction, so I assume that will be a big part
    of our marketing for the release. By avoiding loading DropDownButton and
    it's popup+place dependencies, apps can save downloading 15 pages of code.
    Compared to clients having to add a
    dojo.require("dijit.form.DropDownButton"), that seems like a slam dunk.

    Note that the parser writes a message to the console saying something like
    "dijit.form.ComboButton undefined, did you forget to dojo.require() it?", so
    hopefully even customers that ignored the release notes will see that
    message and know what to do.

    The other thing is that people are going to have migration issues in 1.7
    regardless. For example, <script> tags to load dependencies (either dojo
    widgets or user defined widgets) no longer work. There will be many other
    corner case issues too, which I could give a partial list if people are
    interested.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110523/57fe1a95/attachment.htm
  • Sam foster at May 23, 2011 at 5:35 am
    This is my conservative urge for caution which I put out at every
    release, and some suggestions at the end for how to sell this

    A lot of organizations have backed the Dojo horse because of our
    strict policies around IP, project and API stability. Our guarantees
    of backwards compat are one of the differentiators - its one of the
    sighs of relief we hear when people migrate from jQuery for example.
    Its a sign of maturity and that we understand the costs and effort
    organizations have layered on top of Dojo in their projects.

    Any change that stands between a project/product from simply dropping
    in the latest point release is a headache to someone. There's a great
    deal of FUD associated with any upgrade - it requires a new QA cycle
    at best, and dev resources to migrate a large codebase at worst. We
    can mitigate the worst case by providing a clear migration guide that
    lists a (hopefully small) set of changes necessary to upgrade. Clearly
    the easiest change to make is none at all.

    There are lots of products out there where the code weight is a
    secondary concern. Dojo has always been relatively heavy. Not that
    that's a good thing, but on the whole if people wanted super
    lightweight they picked something else or rolled their own. That means
    that the payback from finer-grained modularization may not be worth
    the cost for people already invested. Its real value is for users we
    don't yet have. I'm generalizing and speculating here; of course it
    will vary, but I think its true to say that many of those users hurt
    most by backward compat breakages also care least about the bytes
    they'll save as a result.

    It may help sell it if we can provide some numbers. Side by side
    waterfall charts for < 1.7 vs. 1.7 for an app of reasonable
    complexity, in a few browsers. Every dojo "customer" has to pitch each
    upgrade - he's what we'll gain, here's what it will involve. If we can
    provide material for that pitch then we'll bring more people along
    with us.

    On the flip side, the prospect of 2.0 being within reach for anyone
    able to track our point releases is *huge*. I think everyone dreads
    that time when their toolkit of choice makes a big jump, forcing them
    to either resign themselves to "legacy" support, or re-tool completely
    (or as likely, pick another toolkit). If we can point to a roadmap
    that shows where we're going, and what needs to change along the way,
    then its easier for project leaders to assess the cost/value and
    create their own plans.

    If think we can address these implicit dependencies in 3 ways:

    * Have a clear "missing dependency" error logged out by the
    loader/dojo.declare where possible. If we know something could break,
    lets add code to watch for and log that error.

    * Have a migration guide that lists what has changed, per module

    * Explain the ROI: why this upgrade is worth the effort. This takes 2
    forms: a roadmap that shows how this is one step on the path towards
    2.0 and all the goodness that brings. And specific numbers for some
    sample that help quantify the gain.

    /Sam
  • Bill Keese at May 24, 2011 at 8:38 pm

    On Mon, May 23, 2011 at 6:35 PM, sam foster wrote:

    * Have a clear "missing dependency" error logged out by the
    loader/dojo.declare where possible. If we know something could break,
    lets add code to watch for and log that error.
    So, with declarative widgets I get a clear error message, at least in
    firefox:

    Could not load class 'dijit.PopupMenuBarItem

    Not sure why you mentioned dojo.declare(), but if you are talking about
    programmatic creation, ex:

    new dijit.CheckedMenuItem(...)

    Then aI'm getting a reasonable error message:

    TypeError: dijit.CheckedMenuItem is not a constructor {
    message="dijit.CheckedMenuItem
    is not a constructor", more...}


    I suppose possibly we could have stub methods like this, but it didn't seem
    worth it to me:

    dijit.CheckedMenuItem = function(){
    throw new Error("The real CheckedMenuItem is not defined, you need to
    require it");
    }


    * Have a migration guide that lists what has changed, per module
    Sure.

    * Explain the ROI: why this upgrade is worth the effort. This takes 2
    forms: a roadmap that shows how this is one step on the path towards
    2.0 and all the goodness that brings. And specific numbers for some
    sample that help quantify the gain.
    Agreed.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110525/ca6b82c4/attachment.htm
  • Mike Wilcox at May 21, 2011 at 1:37 pm

    In 1.6 (and earlier), requiring most dijit widgets would pull in the parser and all of dijit/_base. With the 1.7 push to make granular dependencies, I removed the parser dependency from most widgets. In addition, I'm thinking about making the dijit/_base dependency list more granular (same as we are doing for dojo/_base), in particular to avoid loading the popup and focus code (~1000 lines). The upside is smaller code size, the downside is that apps / custom widgets will have to add in dependencies that they are missing. How do people feel about this?
    I think this question answers itself. When can I use dijit without the parser and when is the parser required? Where it's required it should be automatic, since it's a dependency. I'm guessing it's needed in almost all cases except for a programmatic Dijit not using a template, is this true?
    The other question is about widgets themselves. In 2008 Alex made a separate file for each (non-private) widget, but until 1.7 files like ComboButton.js were just stubs that pointed back to Button.js. I finished splitting up the widget definitions into separate files. This was so apps could avoid pulling in widgets they weren't using, although again the downside is that apps may need to add additional dojo.require() calls. Opinions on this?
    This seems to be primarily an inter-dependency issue. Devs who don't make their own dijits won't be affected nor notice, while devs who do make their own dijits will understand what you did and update their app accordingly when the move to 1.7. If not true, this may be a problem.


    I hope those suggestions were based on a modicum of accuracy :)

    Mike


    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110521/5233a26f/attachment.htm
  • Kenneth G. Franqueiro at May 21, 2011 at 3:59 pm
    Inline...
    On 5/21/2011 1:37 PM, Mike Wilcox wrote:
    In 1.6 (and earlier), requiring most dijit widgets would pull in the
    parser and all of dijit/_base. With the 1.7 push to make granular
    dependencies, I removed the parser dependency from most widgets. In
    addition, I'm thinking about making the dijit/_base dependency list
    more granular (same as we are doing for dojo/_base), in particular to
    avoid loading the popup and focus code (~1000 lines). The upside is
    smaller code size, the downside is that apps / custom widgets will
    have to add in dependencies that they are missing. How do people feel
    about this?
    I think this question answers itself. When can I use dijit without the
    parser and when is the parser required? Where it's required it should be
    automatic, since it's a dependency. I'm guessing it's needed in almost
    all cases except for a programmatic Dijit not using a template, is this
    true?
    If a widget has a template with widgets within it, it requires
    dijit/_WidgetsInTemplateMixin, which transitively requires dojo/parser.
    This is not an issue (and has never been).

    The difference is, this used to all be part of _Templated itself, which
    is required by more widgets than the split-out _WidgetsInTemplateMixin
    now is.

    I'm pretty sure the main concern is cases where people use declarative
    markup to instantiate widgets. In particular, it seems some people have
    a misconception that adding parseOnLoad: true to dojoConfig will
    automatically require parser, which has never been the case.

    Interestingly, I'd note that it would appear dojo.dnd already
    "counteracts" the possibility of this mistake by requiring dojo/parser
    in dojo/dnd/Container, though AFAIK Container doesn't actually use it.
    I guess if this is really seen as an issue to so many people, we might
    be pressed to do the same thing in dijit/_Templated for 1.x, which IINM
    ought to preserve behavior the way it was before.

    My vote on this one is still to teach people to "do it right"; adding a
    require for parser should be a trivial change for clients, no?
    The other question is about widgets themselves. In 2008 Alex made a
    separate file for each (non-private) widget, but until 1.7 files like
    ComboButton.js were just stubs that pointed back to Button.js. I
    finished splitting up the widget definitions into separate files. This
    was so apps could avoid pulling in widgets they weren't using,
    although again the downside is that apps may need to add additional
    dojo.require() calls. Opinions on this?
    This seems to be primarily an inter-dependency issue. Devs who don't
    make their own dijits won't be affected nor notice, while devs who do
    make their own dijits will understand what you did and update their app
    accordingly when the move to 1.7. If not true, this may be a problem.
    The effect of this is far wider than people who write their own widgets.
    I'll try to explain with a couple of examples.

    Example #1: dijit/form/ComboButton

    In 1.6, this simply required dijit/form/Button, then returns ComboButton
    as defined within the Button module. In trunk, ComboButton's definition
    has been split out.

    This means that on <= 1.6, people could potentially be instantiating
    ComboButton while only requiring Button. In trunk that won't work.

    Example #2: MenuItem, PopupMenuItem, CheckedMenuItem, MenuSeparator

    In <=1.6, these were all required by dijit/Menu (with a note to remove
    at 2.0). They have actually been removed in trunk already. Again, this
    means that people could previously instantiate any of these widgets
    while only requiring dijit/Menu, but that will break now.

    It'd kind of be a shame to have to shoot all the added modularity to
    hell (especially since we seem to want mobile to be able to take
    advantage of it), but I have to admit it does look kind of serious from
    a smoothness-of-upgrade perspective, which Chris has voiced serious
    concern over.
    I hope those suggestions were based on a modicum of accuracy :)

    Mike




    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Stephen Chung at May 22, 2011 at 1:41 am
    I have been wondering why setting parseOnLoad to true will not automatically
    pull in the parser. Is there a historical reason?

    - Stephen

    -----Original Message-----
    From: Kenneth G. Franqueiro
    Sent: Sunday, 22 May, 2011 3:59 AM
    To: dojo-contributors at mail.dojotoolkit.org
    Subject: Re: [dojo-contributors] dijit implicit requires

    Inline...
    On 5/21/2011 1:37 PM, Mike Wilcox wrote:
    In 1.6 (and earlier), requiring most dijit widgets would pull in the
    parser and all of dijit/_base. With the 1.7 push to make granular
    dependencies, I removed the parser dependency from most widgets. In
    addition, I'm thinking about making the dijit/_base dependency list
    more granular (same as we are doing for dojo/_base), in particular to
    avoid loading the popup and focus code (~1000 lines). The upside is
    smaller code size, the downside is that apps / custom widgets will
    have to add in dependencies that they are missing. How do people feel
    about this?
    I think this question answers itself. When can I use dijit without the
    parser and when is the parser required? Where it's required it should be
    automatic, since it's a dependency. I'm guessing it's needed in almost
    all cases except for a programmatic Dijit not using a template, is this
    true?
    If a widget has a template with widgets within it, it requires
    dijit/_WidgetsInTemplateMixin, which transitively requires dojo/parser.
    This is not an issue (and has never been).

    The difference is, this used to all be part of _Templated itself, which
    is required by more widgets than the split-out _WidgetsInTemplateMixin
    now is.

    I'm pretty sure the main concern is cases where people use declarative
    markup to instantiate widgets. In particular, it seems some people have
    a misconception that adding parseOnLoad: true to dojoConfig will
    automatically require parser, which has never been the case.

    Interestingly, I'd note that it would appear dojo.dnd already
    "counteracts" the possibility of this mistake by requiring dojo/parser
    in dojo/dnd/Container, though AFAIK Container doesn't actually use it.
    I guess if this is really seen as an issue to so many people, we might
    be pressed to do the same thing in dijit/_Templated for 1.x, which IINM
    ought to preserve behavior the way it was before.

    My vote on this one is still to teach people to "do it right"; adding a
    require for parser should be a trivial change for clients, no?
    The other question is about widgets themselves. In 2008 Alex made a
    separate file for each (non-private) widget, but until 1.7 files like
    ComboButton.js were just stubs that pointed back to Button.js. I
    finished splitting up the widget definitions into separate files. This
    was so apps could avoid pulling in widgets they weren't using,
    although again the downside is that apps may need to add additional
    dojo.require() calls. Opinions on this?
    This seems to be primarily an inter-dependency issue. Devs who don't
    make their own dijits won't be affected nor notice, while devs who do
    make their own dijits will understand what you did and update their app
    accordingly when the move to 1.7. If not true, this may be a problem.
    The effect of this is far wider than people who write their own widgets.
    I'll try to explain with a couple of examples.

    Example #1: dijit/form/ComboButton

    In 1.6, this simply required dijit/form/Button, then returns ComboButton
    as defined within the Button module. In trunk, ComboButton's definition
    has been split out.

    This means that on <= 1.6, people could potentially be instantiating
    ComboButton while only requiring Button. In trunk that won't work.

    Example #2: MenuItem, PopupMenuItem, CheckedMenuItem, MenuSeparator

    In <=1.6, these were all required by dijit/Menu (with a note to remove
    at 2.0). They have actually been removed in trunk already. Again, this
    means that people could previously instantiate any of these widgets
    while only requiring dijit/Menu, but that will break now.

    It'd kind of be a shame to have to shoot all the added modularity to
    hell (especially since we seem to want mobile to be able to take
    advantage of it), but I have to admit it does look kind of serious from
    a smoothness-of-upgrade perspective, which Chris has voiced serious
    concern over.
    I hope those suggestions were based on a modicum of accuracy :)

    Mike




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






    No virus found in this incoming message.
    Checked by AVG - www.avg.com
    Version: 9.0.901 / Virus Database: 271.1.1/3652 - Release Date: 05/22/11
    02:34:00
  • Bill Keese at May 22, 2011 at 3:05 am
    I remember that for 0.9 we stopped pulling in the parser as part of dojo.js
    to avoid the unneeded load (when the page didn't use the parser)... but
    about pulling it in conditionally when parseOnLoad is set, that's probably a
    good idea. It would address the most common problem w.r.t. parser being
    not loaded, w/out loading it in unnecessary cases.

    On Sun, May 22, 2011 at 2:41 PM, Stephen Chung
    wrote:
    I have been wondering why setting parseOnLoad to true will not
    automatically
    pull in the parser. Is there a historical reason?

    - Stephen

    -----Original Message-----
    From: Kenneth G. Franqueiro
    Sent: Sunday, 22 May, 2011 3:59 AM
    To: dojo-contributors at mail.dojotoolkit.org
    Subject: Re: [dojo-contributors] dijit implicit requires

    Inline...
    On 5/21/2011 1:37 PM, Mike Wilcox wrote:
    In 1.6 (and earlier), requiring most dijit widgets would pull in the
    parser and all of dijit/_base. With the 1.7 push to make granular
    dependencies, I removed the parser dependency from most widgets. In
    addition, I'm thinking about making the dijit/_base dependency list
    more granular (same as we are doing for dojo/_base), in particular to
    avoid loading the popup and focus code (~1000 lines). The upside is
    smaller code size, the downside is that apps / custom widgets will
    have to add in dependencies that they are missing. How do people feel
    about this?
    I think this question answers itself. When can I use dijit without the
    parser and when is the parser required? Where it's required it should be
    automatic, since it's a dependency. I'm guessing it's needed in almost
    all cases except for a programmatic Dijit not using a template, is this
    true?
    If a widget has a template with widgets within it, it requires
    dijit/_WidgetsInTemplateMixin, which transitively requires dojo/parser.
    This is not an issue (and has never been).

    The difference is, this used to all be part of _Templated itself, which
    is required by more widgets than the split-out _WidgetsInTemplateMixin
    now is.

    I'm pretty sure the main concern is cases where people use declarative
    markup to instantiate widgets. In particular, it seems some people have
    a misconception that adding parseOnLoad: true to dojoConfig will
    automatically require parser, which has never been the case.

    Interestingly, I'd note that it would appear dojo.dnd already
    "counteracts" the possibility of this mistake by requiring dojo/parser
    in dojo/dnd/Container, though AFAIK Container doesn't actually use it.
    I guess if this is really seen as an issue to so many people, we might
    be pressed to do the same thing in dijit/_Templated for 1.x, which IINM
    ought to preserve behavior the way it was before.

    My vote on this one is still to teach people to "do it right"; adding a
    require for parser should be a trivial change for clients, no?
    The other question is about widgets themselves. In 2008 Alex made a
    separate file for each (non-private) widget, but until 1.7 files like
    ComboButton.js were just stubs that pointed back to Button.js. I
    finished splitting up the widget definitions into separate files. This
    was so apps could avoid pulling in widgets they weren't using,
    although again the downside is that apps may need to add additional
    dojo.require() calls. Opinions on this?
    This seems to be primarily an inter-dependency issue. Devs who don't
    make their own dijits won't be affected nor notice, while devs who do
    make their own dijits will understand what you did and update their app
    accordingly when the move to 1.7. If not true, this may be a problem.
    The effect of this is far wider than people who write their own widgets.
    I'll try to explain with a couple of examples.

    Example #1: dijit/form/ComboButton

    In 1.6, this simply required dijit/form/Button, then returns ComboButton
    as defined within the Button module. In trunk, ComboButton's definition
    has been split out.

    This means that on <= 1.6, people could potentially be instantiating
    ComboButton while only requiring Button. In trunk that won't work.

    Example #2: MenuItem, PopupMenuItem, CheckedMenuItem, MenuSeparator

    In <=1.6, these were all required by dijit/Menu (with a note to remove
    at 2.0). They have actually been removed in trunk already. Again, this
    means that people could previously instantiate any of these widgets
    while only requiring dijit/Menu, but that will break now.

    It'd kind of be a shame to have to shoot all the added modularity to
    hell (especially since we seem to want mobile to be able to take
    advantage of it), but I have to admit it does look kind of serious from
    a smoothness-of-upgrade perspective, which Chris has voiced serious
    concern over.
    I hope those suggestions were based on a modicum of accuracy :)

    Mike




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






    No virus found in this incoming message.
    Checked by AVG - www.avg.com
    Version: 9.0.901 / Virus Database: 271.1.1/3652 - Release Date: 05/22/11
    02:34:00

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110522/e9f04cde/attachment-0001.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedMay 21, '11 at 12:50a
activeMay 24, '11 at 8:38p
posts10
users6
websitedojotoolkit.org

People

Translate

site design / logo © 2021 Grokbase