A while back somebody asked about the road map for Dojo 2.0, and I
finally gave some thought to dijit.

There are lots of things people want for the future of dijit, documented
(among other places) in:

* http://dojotoolkit.org/2007/08/12/widget-wish-list
* http://www.dojotoolkit.org/2007/11/21/widget-wish-list-response
* http://www.dojotoolkit.org/2008/09/17/dijit-1-3
* http://bugs.dojotoolkit.org/report/19

Most of those tasks, though, could be done either before or after 2.0,
so they don't need to be tied to the 2.0 release. What I'm looking at
is the changes that require changes in back-compatibility.
Specifically my thoughts are:


General:

* remove deprecated code (setValue(), etc.)
* remove deprecated widgets (SplitContainer, LayoutContainer)
* finish up file split by widget (Button.js and Checkbox.js remain)


Rename files/classes/directories:

* Textarea --> ResizableTextArea/AutoSizingTextArea (note case change).
* SimpleTextarea --> TextArea (note case change)
* _editor --> editor (since plugins aren't really private)
* _tree --> tree (since dijit._tree.dndSource isn't private)
* _Widget --> WidgetBase, _Templated --> TemplatedMixin (since they
are not really private)
* some (but not all) of these changes could be done now, with
back-compat stubs


Widget:

* rename destroyRecursive() to destroy() and get rid of uninitialize()
* move attributeMap to a mixin?


Widget Attributes Schema/Parser changes:

* require widgets to declare their public attributes (a.k.a.
parameters) explicitly, along w/how to get the parameters from markup
(from DOM node attributes or from innerHTML via CSS expression)

* widgets no longer need to query srcNodeRef to get their more complex
parameters

* parser also has support for Container widgets; parser will call
addChild() for each child, or maybe pass in a children[] array of
widgets to the parent widget's constructor

* parser stops at ContentPane; ContentPane will parse it's own content
when it is displayed. ie, defer parsing of hidden panes in TabContainer.


Widget Events:

* Users call Widget.subscribe() or Widget.connect() method for
monitoring events (like onClick) on a widget, rather than calling
dojo.connect()
* This removes the need for widgets to implement empty onClick() type
functions
* Not sure about documentation, I guess the events each widget
supports would need to be listed in the widget description

Themes and CSS:

* if we want themes to be able to control non-CSS behavior (like
animations), then we probably have to modify the way users specify the
theme(s) for a page. Instead of setting <body class="tundra"> maybe the
theme would be a djConfig variable, and to override a theme for a
particular widget would require setting theme="soria" on that widget.

* was it a mistake to remove templateCssPath in 1.0? I have to think
about this some more, but anyway, 2.0 is a chance to change how we deal
with CSS.

TabContainer and friends:

* remove topics from StackContainer? Can just use simple events.
* remove StackController altogether? Probably no one is using it.
* TabContainer implementation can be simplified by removing controller
paradigm (which lets user can create a TabController separately from the
TabContainer). Rather just combine into one widget.


Build stage?

* For theme generation (from template files) and possibly other things
I wonder if it makes sense to require a build step. Obviously there are
some disadvantages but I wonder if the pros outweigh the cons. Have to
think about that one.
* A build could also solve NLS issues such as locale file generation
(right now a raw checkout only supports a few locales), plus the famous
404 error trying to load language files that don't exist.


Private / Protected / Public:

* The _foo naming method doesn't work since it can't distinguish
private from protected, and also since many of our protected methods
don't have an underscore, like postCreate(). I guess though this is
just a question of putting that metadata in comments, so this isn't a
2.0 issue per se.


Mixins (suggestion from dylan):

* Make more things mixins. I was told recently that a11y and i18n
should be mixins rather than requirements because some apps do not need
them.



Anyway, those are just some initial thoughts.

Bill

Search Discussions

  • Shane O'Sullivan at Jan 22, 2009 at 5:07 am
    Hi Bill,

    With regards to themes, what is really required is some considerable
    work to bring them to the same level of look and feel as the best of
    the other toolkits. For example, SmartClient and ExtJs are both more
    visually pleasing that Dijit, even though they may not have the same
    strong technological foundation. This can make it very difficult to
    sell Dijit when it is compared directly to some of these other
    toolkits.

    Of course, this does not have to wait for 2.0.

    Thanks

    Shane

    2009/1/22 Bill Keese <bill at dojotoolkit.org>:
    A while back somebody asked about the road map for Dojo 2.0, and I
    finally gave some thought to dijit.

    There are lots of things people want for the future of dijit, documented
    (among other places) in:

    * http://dojotoolkit.org/2007/08/12/widget-wish-list
    * http://www.dojotoolkit.org/2007/11/21/widget-wish-list-response
    * http://www.dojotoolkit.org/2008/09/17/dijit-1-3
    * http://bugs.dojotoolkit.org/report/19

    Most of those tasks, though, could be done either before or after 2.0,
    so they don't need to be tied to the 2.0 release. What I'm looking at
    is the changes that require changes in back-compatibility.
    Specifically my thoughts are:


    General:

    * remove deprecated code (setValue(), etc.)
    * remove deprecated widgets (SplitContainer, LayoutContainer)
    * finish up file split by widget (Button.js and Checkbox.js remain)


    Rename files/classes/directories:

    * Textarea --> ResizableTextArea/AutoSizingTextArea (note case change).
    * SimpleTextarea --> TextArea (note case change)
    * _editor --> editor (since plugins aren't really private)
    * _tree --> tree (since dijit._tree.dndSource isn't private)
    * _Widget --> WidgetBase, _Templated --> TemplatedMixin (since they
    are not really private)
    * some (but not all) of these changes could be done now, with
    back-compat stubs


    Widget:

    * rename destroyRecursive() to destroy() and get rid of uninitialize()
    * move attributeMap to a mixin?


    Widget Attributes Schema/Parser changes:

    * require widgets to declare their public attributes (a.k.a.
    parameters) explicitly, along w/how to get the parameters from markup
    (from DOM node attributes or from innerHTML via CSS expression)

    * widgets no longer need to query srcNodeRef to get their more complex
    parameters

    * parser also has support for Container widgets; parser will call
    addChild() for each child, or maybe pass in a children[] array of
    widgets to the parent widget's constructor

    * parser stops at ContentPane; ContentPane will parse it's own content
    when it is displayed. ie, defer parsing of hidden panes in TabContainer.


    Widget Events:

    * Users call Widget.subscribe() or Widget.connect() method for
    monitoring events (like onClick) on a widget, rather than calling
    dojo.connect()
    * This removes the need for widgets to implement empty onClick() type
    functions
    * Not sure about documentation, I guess the events each widget
    supports would need to be listed in the widget description

    Themes and CSS:

    * if we want themes to be able to control non-CSS behavior (like
    animations), then we probably have to modify the way users specify the
    theme(s) for a page. Instead of setting <body class="tundra"> maybe the
    theme would be a djConfig variable, and to override a theme for a
    particular widget would require setting theme="soria" on that widget.

    * was it a mistake to remove templateCssPath in 1.0? I have to think
    about this some more, but anyway, 2.0 is a chance to change how we deal
    with CSS.

    TabContainer and friends:

    * remove topics from StackContainer? Can just use simple events.
    * remove StackController altogether? Probably no one is using it.
    * TabContainer implementation can be simplified by removing controller
    paradigm (which lets user can create a TabController separately from the
    TabContainer). Rather just combine into one widget.


    Build stage?

    * For theme generation (from template files) and possibly other things
    I wonder if it makes sense to require a build step. Obviously there are
    some disadvantages but I wonder if the pros outweigh the cons. Have to
    think about that one.
    * A build could also solve NLS issues such as locale file generation
    (right now a raw checkout only supports a few locales), plus the famous
    404 error trying to load language files that don't exist.


    Private / Protected / Public:

    * The _foo naming method doesn't work since it can't distinguish
    private from protected, and also since many of our protected methods
    don't have an underscore, like postCreate(). I guess though this is
    just a question of putting that metadata in comments, so this isn't a
    2.0 issue per se.


    Mixins (suggestion from dylan):

    * Make more things mixins. I was told recently that a11y and i18n
    should be mixins rather than requirements because some apps do not need
    them.



    Anyway, those are just some initial thoughts.

    Bill


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bill Keese at Jan 22, 2009 at 8:37 pm

    Shane O'Sullivan wrote:
    Hi Bill,

    With regards to themes, what is really required is some considerable
    work to bring them to the same level of look and feel as the best of
    the other toolkits.
    Hi Shane, I don't disagree with you. Actually I spend a lot of my time
    working on this, but it's slow going. Any help is appreciated.

    And as you said, it doesn't need to be tied to 2.0.
  • Shane O'Sullivan at Jan 23, 2009 at 4:36 am
    Hi Bill,

    While I'd love to help, I'd be just another engineer - is there any
    chance we could get a decent graphic designer or three from any of
    Dojo's big backers? They're what's really needed.

    Shane

    2009/1/23 Bill Keese <bill at dojotoolkit.org>:
    Shane O'Sullivan wrote:
    Hi Bill,

    With regards to themes, what is really required is some considerable
    work to bring them to the same level of look and feel as the best of
    the other toolkits.
    Hi Shane, I don't disagree with you. Actually I spend a lot of my time
    working on this, but it's slow going. Any help is appreciated.

    And as you said, it doesn't need to be tied to 2.0.
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bill Keese at Jan 24, 2009 at 12:12 am

    Shane O'Sullivan wrote:
    Hi Bill,

    While I'd love to help, I'd be just another engineer - is there any
    chance we could get a decent graphic designer or three from any of
    Dojo's big backers? They're what's really needed.
    Hi Shane,

    I think IBM will be contributing to this more soon, but more on that
    next week. As for the other big backers like Sitepen I can't comment,
    but of course any help would be appreciated.

    I think though too that a lot of the work is more engineer focused than
    designer focused. For example, the thing about ComboButton being a
    different height than DropDownButton or plain Button is more of an
    engineering problem as it's because of using tables for ComboButton but
    not the others. Or the idea of having fade-in/fade-out on all popups,
    the hard part is implementation, because it leads to timing race
    conditions etc.

    In other words, once the designers decide the way that it should look,
    either they or we can implement it. Of course stuff like icons and
    color choices should come from the designers.

    Bill
  • Dylan Schiemann at Jan 25, 2009 at 8:21 am

    Bill Keese wrote:
    Shane O'Sullivan wrote:
    Hi Bill,

    While I'd love to help, I'd be just another engineer - is there any
    chance we could get a decent graphic designer or three from any of
    Dojo's big backers? They're what's really needed.
    Hi Shane,

    I think IBM will be contributing to this more soon, but more on that
    next week. As for the other big backers like Sitepen I can't comment,
    but of course any help would be appreciated.

    I think though too that a lot of the work is more engineer focused than
    designer focused. For example, the thing about ComboButton being a
    different height than DropDownButton or plain Button is more of an
    engineering problem as it's because of using tables for ComboButton but
    not the others. Or the idea of having fade-in/fade-out on all popups,
    the hard part is implementation, because it leads to timing race
    conditions etc.

    In other words, once the designers decide the way that it should look,
    either they or we can implement it. Of course stuff like icons and
    color choices should come from the designers.

    Bill
    I think our issues are a bit in between the traditional realm of visual
    design (icons/color choices) and engineering (implement said icons and
    color choices).

    I'm sure you've heard Alex's description of "fit and finish". It's that
    last 10% of polish, which is behavior and interaction design, that
    defines how long an animation lasts, how a widget behaves, etc., that we
    struggle with at times, and which people have been working on. As you
    said, consistency is definitely one part of that, and it's the need to
    be stubbornly obsessive with making each widget perfect in every way
    that we haven't reached yet.

    Regards,
    - -Dylan
  • Nathan Toone at Jan 25, 2009 at 9:34 am

    On Jan 25, 2009, at 6:21 AM, Dylan Schiemann wrote:

    I'm sure you've heard Alex's description of "fit and finish". It's
    that
    last 10% of polish, which is behavior and interaction design, that
    defines how long an animation lasts, how a widget behaves, etc.,
    that we
    struggle with at times, and which people have been working on. As you
    said, consistency is definitely one part of that, and it's the need to
    be stubbornly obsessive with making each widget perfect in every way
    that we haven't reached yet.
    I would also argue that it's not just making sure that each widget is
    perfect in every way that we haven't reached...but that each widget
    "melds" well with all other widgets that we haven't yet reached
    eithers. The example of ComboButton vs other buttons is one case.

    -Nathan
  • Mark Wubben at Jan 26, 2009 at 4:45 am

    On Jan 25, 2009, at 14:21 , Dylan Schiemann wrote:
    I think our issues are a bit in between the traditional realm of
    visual
    design (icons/color choices) and engineering (implement said icons and
    color choices).

    I'm sure you've heard Alex's description of "fit and finish". It's
    that
    last 10% of polish, which is behavior and interaction design, that
    defines how long an animation lasts, how a widget behaves, etc.,
    that we
    struggle with at times, and which people have been working on. As you
    said, consistency is definitely one part of that, and it's the need to
    be stubbornly obsessive with making each widget perfect in every way
    that we haven't reached yet.
    Perhaps one problem is that 'fit and finish' shouldn't come after 90%
    of the work is done. It means the interface designer can only style
    what the programmer thought was necessary, instead of specifying a
    good interface that is *then* implemented, and later styled.

    For example, I've found it takes quite some workarounds to implement
    something similar to <http://mir.aculo.us/2009/1/7/using-input-values-as-hints-the-easy-way
    , but it's worth it, because that's a nicer interface than Dijit's
    prompt message tooltips.

    --
    Mark Wubben
    +45 53 47 59 42

    http://supercollider.dk
  • Mike Wilcox at Jan 26, 2009 at 8:07 am
    I guess it would be: Dojo Extensions for Adobe AIR

    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: 214.697.4872
    On Jan 25, 2009, at 7:21 AM, Dylan Schiemann wrote:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Bill Keese wrote:
    Shane O'Sullivan wrote:
    Hi Bill,

    While I'd love to help, I'd be just another engineer - is there any
    chance we could get a decent graphic designer or three from any of
    Dojo's big backers? They're what's really needed.
    Hi Shane,

    I think IBM will be contributing to this more soon, but more on that
    next week. As for the other big backers like Sitepen I can't
    comment,
    but of course any help would be appreciated.

    I think though too that a lot of the work is more engineer focused
    than
    designer focused. For example, the thing about ComboButton being a
    different height than DropDownButton or plain Button is more of an
    engineering problem as it's because of using tables for ComboButton
    but
    not the others. Or the idea of having fade-in/fade-out on all
    popups,
    the hard part is implementation, because it leads to timing race
    conditions etc.

    In other words, once the designers decide the way that it should
    look,
    either they or we can implement it. Of course stuff like icons and
    color choices should come from the designers.

    Bill
    I think our issues are a bit in between the traditional realm of
    visual
    design (icons/color choices) and engineering (implement said icons and
    color choices).

    I'm sure you've heard Alex's description of "fit and finish". It's
    that
    last 10% of polish, which is behavior and interaction design, that
    defines how long an animation lasts, how a widget behaves, etc.,
    that we
    struggle with at times, and which people have been working on. As you
    said, consistency is definitely one part of that, and it's the need to
    be stubbornly obsessive with making each widget perfect in every way
    that we haven't reached yet.

    Regards,
    - -Dylan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFJfGdI8nLgh/JJsxERAhaMAKCAplbH7O2nW6TA6wrsSEIwL2wguQCfVwEd
    aq2LVjEs79K01o3NIYYofPo=
    =NBZO
    -----END PGP SIGNATURE-----
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Mike Wilcox at Jan 26, 2009 at 8:12 am
    What the heck! Replied to the wrong email.

    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: 214.697.4872
    On Jan 26, 2009, at 7:07 AM, Mike Wilcox wrote:

    I guess it would be: Dojo Extensions for Adobe AIR

    Mike Wilcox
    mwilcox at sitepen.com
    http://www.sitepen.com
    work: 650.968.8787 x218
    cell: 214.697.4872
    On Jan 25, 2009, at 7:21 AM, Dylan Schiemann wrote:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Bill Keese wrote:
    Shane O'Sullivan wrote:
    Hi Bill,

    While I'd love to help, I'd be just another engineer - is there any
    chance we could get a decent graphic designer or three from any of
    Dojo's big backers? They're what's really needed.
    Hi Shane,

    I think IBM will be contributing to this more soon, but more on that
    next week. As for the other big backers like Sitepen I can't
    comment,
    but of course any help would be appreciated.

    I think though too that a lot of the work is more engineer focused
    than
    designer focused. For example, the thing about ComboButton being a
    different height than DropDownButton or plain Button is more of an
    engineering problem as it's because of using tables for ComboButton
    but
    not the others. Or the idea of having fade-in/fade-out on all
    popups,
    the hard part is implementation, because it leads to timing race
    conditions etc.

    In other words, once the designers decide the way that it should
    look,
    either they or we can implement it. Of course stuff like icons and
    color choices should come from the designers.

    Bill
    I think our issues are a bit in between the traditional realm of
    visual
    design (icons/color choices) and engineering (implement said icons
    and
    color choices).

    I'm sure you've heard Alex's description of "fit and finish". It's
    that
    last 10% of polish, which is behavior and interaction design, that
    defines how long an animation lasts, how a widget behaves, etc.,
    that we
    struggle with at times, and which people have been working on. As
    you
    said, consistency is definitely one part of that, and it's the need
    to
    be stubbornly obsessive with making each widget perfect in every way
    that we haven't reached yet.

    Regards,
    - -Dylan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFJfGdI8nLgh/JJsxERAhaMAKCAplbH7O2nW6TA6wrsSEIwL2wguQCfVwEd
    aq2LVjEs79K01o3NIYYofPo=
    =NBZO
    -----END PGP SIGNATURE-----
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Mark Wubben at Jan 22, 2009 at 5:26 pm
    I'm not sure whether this has been brought up before, or if this is
    the place to do so, but Inline Templates, a <http://www.sitepen.com/blog/2008/06/24/creating-dojo-widgets-with-inline-templates/
    would be rather interesting. My current use case is a setup where
    Dijit reuses the same template client-side as is used on the server-
    side.
    On Jan 22, 2009, at 1:54 , Bill Keese wrote:

    A while back somebody asked about the road map for Dojo 2.0, and I
    finally gave some thought to dijit.

    There are lots of things people want for the future of dijit,
    documented
    (among other places) in:

    * http://dojotoolkit.org/2007/08/12/widget-wish-list
    * http://www.dojotoolkit.org/2007/11/21/widget-wish-list-response
    * http://www.dojotoolkit.org/2008/09/17/dijit-1-3
    * http://bugs.dojotoolkit.org/report/19

    Most of those tasks, though, could be done either before or after 2.0,
    so they don't need to be tied to the 2.0 release. What I'm looking at
    is the changes that require changes in back-compatibility.
    Specifically my thoughts are:


    General:

    * remove deprecated code (setValue(), etc.)
    * remove deprecated widgets (SplitContainer, LayoutContainer)
    * finish up file split by widget (Button.js and Checkbox.js remain)


    Rename files/classes/directories:

    * Textarea --> ResizableTextArea/AutoSizingTextArea (note case
    change).
    * SimpleTextarea --> TextArea (note case change)
    * _editor --> editor (since plugins aren't really private)
    * _tree --> tree (since dijit._tree.dndSource isn't private)
    * _Widget --> WidgetBase, _Templated --> TemplatedMixin (since they
    are not really private)
    * some (but not all) of these changes could be done now, with
    back-compat stubs


    Widget:

    * rename destroyRecursive() to destroy() and get rid of
    uninitialize()
    * move attributeMap to a mixin?


    Widget Attributes Schema/Parser changes:

    * require widgets to declare their public attributes (a.k.a.
    parameters) explicitly, along w/how to get the parameters from markup
    (from DOM node attributes or from innerHTML via CSS expression)

    * widgets no longer need to query srcNodeRef to get their more
    complex
    parameters

    * parser also has support for Container widgets; parser will call
    addChild() for each child, or maybe pass in a children[] array of
    widgets to the parent widget's constructor

    * parser stops at ContentPane; ContentPane will parse it's own
    content
    when it is displayed. ie, defer parsing of hidden panes in
    TabContainer.


    Widget Events:

    * Users call Widget.subscribe() or Widget.connect() method for
    monitoring events (like onClick) on a widget, rather than calling
    dojo.connect()
    * This removes the need for widgets to implement empty onClick() type
    functions
    * Not sure about documentation, I guess the events each widget
    supports would need to be listed in the widget description

    Themes and CSS:

    * if we want themes to be able to control non-CSS behavior (like
    animations), then we probably have to modify the way users specify the
    theme(s) for a page. Instead of setting <body class="tundra"> maybe
    the
    theme would be a djConfig variable, and to override a theme for a
    particular widget would require setting theme="soria" on that widget.

    * was it a mistake to remove templateCssPath in 1.0? I have to
    think
    about this some more, but anyway, 2.0 is a chance to change how we
    deal
    with CSS.

    TabContainer and friends:

    * remove topics from StackContainer? Can just use simple events.
    * remove StackController altogether? Probably no one is using it.
    * TabContainer implementation can be simplified by removing
    controller
    paradigm (which lets user can create a TabController separately from
    the
    TabContainer). Rather just combine into one widget.


    Build stage?

    * For theme generation (from template files) and possibly other
    things
    I wonder if it makes sense to require a build step. Obviously there
    are
    some disadvantages but I wonder if the pros outweigh the cons.
    Have to
    think about that one.
    * A build could also solve NLS issues such as locale file generation
    (right now a raw checkout only supports a few locales), plus the
    famous
    404 error trying to load language files that don't exist.


    Private / Protected / Public:

    * The _foo naming method doesn't work since it can't distinguish
    private from protected, and also since many of our protected methods
    don't have an underscore, like postCreate(). I guess though this is
    just a question of putting that metadata in comments, so this isn't a
    2.0 issue per se.


    Mixins (suggestion from dylan):

    * Make more things mixins. I was told recently that a11y and i18n
    should be mixins rather than requirements because some apps do not
    need
    them.



    Anyway, those are just some initial thoughts.

    Bill


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
    --
    Mark Wubben
    +45 53 47 59 42

    http://supercollider.dk
  • Bill Keese at Jan 22, 2009 at 8:46 pm

    Mark Wubben wrote:
    I'm not sure whether this has been brought up before, or if this is
    the place to do so, but Inline Templates, a <http://www.sitepen.com/blog/2008/06/24/creating-dojo-widgets-with-inline-templates/
    would be rather interesting. My current use case is a setup where
    Dijit reuses the same template client-side as is used on the server-
    side.
    Hi Mark,

    Yes, this comes up every 6 months or so. Usually described as
    "pre-instantiating" widgets on the server, to prevent screen glitches
    during loading and/or to speed up loading. It sounds like a great idea
    except for the developement/maintenance cost.

    Bill
  • Dustin Machi at Jan 22, 2009 at 8:57 pm
    This isn't the same as pre-instantiating, though there are
    similarities. This is more useful when you want to apply a widget to a
    variable template (originally i used something similar as a form
    wrapper, and I believe Eugene's dojox.form.manager mixin does
    something similar.

    Dustin
    On Jan 22, 2009, at 8:46 PM, Bill Keese wrote:

    Mark Wubben wrote:
    I'm not sure whether this has been brought up before, or if this is
    the place to do so, but Inline Templates, a <http://www.sitepen.com/blog/2008/06/24/creating-dojo-widgets-with-inline-templates/
    would be rather interesting. My current use case is a setup where
    Dijit reuses the same template client-side as is used on the server-
    side.
    Hi Mark,

    Yes, this comes up every 6 months or so. Usually described as
    "pre-instantiating" widgets on the server, to prevent screen glitches
    during loading and/or to speed up loading. It sounds like a great
    idea
    except for the developement/maintenance cost.

    Bill
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
    Dustin Machi
    http://www.sitepen.com
    dmachi at sitepen.com
  • Eugene Lazutkin at Jan 22, 2009 at 10:00 pm
    The pre-instantiation and dynamic instantiation (like in the form
    manager) are good techniques, but they work best with the server-side
    support. Without it the pre-instantiation is a liability.

    Another thing is how to convey the state the HTML was (pre)rendered. It
    would be better to have something simple, yet more-or-less unified for
    different widgets.

    Eugene Lazutkin
    Dojo Toolkit, Committer
    SitePen, Developer


    Bill Keese wrote:
    Mark Wubben wrote:
    I'm not sure whether this has been brought up before, or if this is
    the place to do so, but Inline Templates, a <http://www.sitepen.com/blog/2008/06/24/creating-dojo-widgets-with-inline-templates/
    would be rather interesting. My current use case is a setup where
    Dijit reuses the same template client-side as is used on the server-
    side.
    Hi Mark,

    Yes, this comes up every 6 months or so. Usually described as
    "pre-instantiating" widgets on the server, to prevent screen glitches
    during loading and/or to speed up loading. It sounds like a great idea
    except for the developement/maintenance cost.

    Bill
  • Rawld Gill at Jan 23, 2009 at 4:31 am
    Hey Bill,

    I've been going through dijit pretty extensively the last few weeks as part
    of a major project I'm working on. Dijit is really well done and contains
    many pleasant surprises (e.g., dijit.focus). You and the rest of the dijit
    team have done a great job.

    Here are some of thoughts about the future of dijit:

    1.
    There is a tendency to try to stuff everything into a class. Sometimes this
    has two bad side effects: (1) decreased availability of an otherwise
    generally useful function and (2) increased complexity without an associated
    benefit.

    An example of [1] is dijit.form._FormWidget._setStateClass. This function is
    quite useful in several different classes of widgets-some that may not
    derive from dijit.form._FormWidget.

    An example of [2] is dijit._Widget._attrPairNames/_getAttrNames. At best
    these are so-called class-methods (static in C++), not instance methods. I
    really think they ought to be completely out of the class hierarchy and live
    as module functions.

    These are minor points to dijit users. But they are more painful for dijit
    creators/maintainers. The easier it is to read and understand how dijit
    works and the easier it is to build new widgets completely independent of
    most of the existing hierarchy, the more people we will have doing so. And
    this is good for the toolkit. Naturally, the converse is also true.

    2.
    The hack where BorderContainer extends all widgets with the properties
    region, splitter, etc. identifies the general problem of parent widgets
    desiring to keep child-dependent properties in their children. This problem
    can be solved in a general way by adding the property "parentSpace" to all
    widgets together with additional machinery for getting/setting property
    values in this space (much like attr)(should be added as a mixin). I've got
    an implementation; let me know if you want it.

    3.
    Naming is often overly complex. To begin with, why is dijit._Widget marked
    with an underscore? Does dijit really intend to say, "this is subject to
    changes and don't count on it." Or even worse, "this is magic, and don't
    attempt to use it."

    There are many places where the leading underscore hedge is used. For
    example, dijit.focus has the objects _curFocus, _prevFocus, and
    _activeStack-all highly useful. These and others should be published for the
    world to see how great dijit really is.

    It seems to me that there is confusion between module namespaces, JavaScript
    filenames, and widget names. These are all different things. While the code
    decomposition seems quite reasonable, the assigning of widget names does
    not. For example, dijit has widgets named dijit.form.Checkbox and
    dijit.layout.BorderContainer-which begs the questions "are there so many
    widgets that this division is necessary?" And, "is there any chance of
    confusing a checkbox from a border container?" It would be quite simple to
    put each widget constructor as a property of dijit (e.g., dijit.Checkbox,
    dijit.BorderContainer), and this could be done without reorg of any existing
    code. This would be easier to understand for novices and easier to type for
    all.

    I know I'll probably get yelled at for suggesting this...but, why do classes
    have to start with a cap!? What does it gain? Nothing else is leading cap'd.

    In short, I would suggest: eliminate as many underscore prefixed names as
    possible, shorten names as much as possible, and get rid of the leading cap
    (ducking).

    4.
    The capability to mix and match different capabilities (traits) into a
    widget at the time of construction rather than at the time of class
    definition. For example, the FormValueWidget undo machinery supports a very
    limited undo model that gets in the way of a more substantial undo model
    (e.g. a model that maintains a session undo stack). In some places dijit
    rolls these little nuggets of functionality into the class even though they
    are largely orthogonal to the real purpose of the class. These nuggets add
    complexity if you don't need them and make more work if you're doing
    something completely different. (Of course the counter argument is...if you
    do need them, they decrease complexity.)

    Another, perhaps better approach would be to specify the instance
    capabilities at construction time. For example, I may want a validating text
    box that binds to a specialized data source and uses a session-wide undo
    stack for one purpose and also want a validating text box, not bound to
    anything, with the current widget-level undo machinery for another purpose.
    Designing such a capability would probably require a bit of work on
    dojo.declare. If you have interest in this let me know and I'll try to work
    together a prototype.

    5.
    Mouse capture machinery should be factored out of existing code and
    published. I'm pretty sure Eugene has it in DnD, you've got some in
    BorderContainer, and I've built generic/cross-browser capture machinery for
    my stuff (let me know if you want it).

    6.
    Seems like the events in dijit.focus should be connected using dojo.connect
    and the event objects should be passed to the handlers.

    7.
    There is no accelerator key machinery. I've got some; happy to contribute.

    8.
    In many places the code contains _local_ "var d= dojo". Consider
    constructing each module with the following pattern:

    (function() {
    var
    d= dojo,
    thisModule= d.provide("dijit.some.module");

    //module contents goes here
    //you can use d for dojo everywhere to your hearts content

    })();

    Notice that this pattern allows easily adding objects to the module
    namespace ("thisModule" gets optimized down to 2 characters with
    shrinksafe). If this pattern is pervasive, using "d" for dojo results in no
    obfuscation. I know this has been discussed elsewhere; not sure I ever
    understood a conclusion to that discussion.

    9.
    I'm not totally convinced of the design of
    dijit._contained/dijit._container. It seems like they are reflecting the DOM
    tree into the widget tree, but the trees may in fact be far from 1-to-1,
    onto. Consider an alternative design where container just maintains an array
    of children. This has some advantages: children need not precisely reflect
    the DOM tree, children need not be instantiated (or can be lazy
    instantiated); fast retrieval along several axes; very simple traversal
    (startup, destroy, apply) routines. I admit that my use cases could be quite
    different than what _container was designed for...so my argument may be weak
    here.

    10.
    _KeyNavContainer can't be easily (naturally) mixed in to _LayoutWidget.
    Seems like _KeyNavContainer should be a separate mixin. But I haven't
    investigated this deeply since _KeyNavContainer didn't meet my
    requirements. Let me know if you're interested in looking at something more
    substantial here (for _KeyNavContainer).

    11.
    It's been said elsewhere...the style sheets always need work. This seems to
    be a black art sometimes.

    Best,
    Rawld



    __________ Information from ESET NOD32 Antivirus, version of virus signature
    database 3791 (20090122) __________

    The message was checked by ESET NOD32 Antivirus.

    http://www.eset.com
  • Bill Keese at Jan 23, 2009 at 11:02 am
    Hi Rawld, wow thanks for the thought through response. Lots of good
    stuff in your email, addressed inline:


    Rawld Gill wrote:
    1.
    There is a tendency to try to stuff everything into a class. Sometimes this
    has two bad side effects: (1) decreased availability of an otherwise
    generally useful function and (2) increased complexity without an associated
    benefit.

    An example of [1] is dijit.form._FormWidget._setStateClass. This function is
    quite useful in several different classes of widgets-some that may not
    derive from dijit.form._FormWidget.
    Fair enough... of course you can always access those functions though
    the prototype, like

    dijit.form._FormWidget.prototype._setStateClass.call(context);

    but admittedly that's lame.

    I wouldn't mind pulling out any methods you think developers want to
    call directly (maybe you can even supply a patch for this or we could
    work on it together). Would have to figure out what signature makes
    sense for each function, of course, for setStateClass maybe something
    like setStateClass(flags, domNode).

    Actually that work isn't tied to 2.0, it could be done anytime.

    An example of [2] is dijit._Widget._attrPairNames/_getAttrNames. At best
    these are so-called class-methods (static in C++), not instance methods. I
    really think they ought to be completely out of the class hierarchy and live
    as module functions.
    Your argument is that putting these static methods into the class is
    "increased complexity". Hmm, perhaps. It's a bit philosophical. Are
    class methods always bad? The idea was to hide_getAttrNames since it's
    just a helper for attr().

    These are minor points to dijit users. But they are more painful for dijit
    creators/maintainers. The easier it is to read and understand how dijit
    works and the easier it is to build new widgets completely independent of
    most of the existing hierarchy, the more people we will have doing so. And
    this is good for the toolkit. Naturally, the converse is also true.
    2.
    The hack where BorderContainer extends all widgets with the properties
    region, splitter, etc. identifies the general problem of parent widgets
    desiring to keep child-dependent properties in their children. This problem
    can be solved in a general way by adding the property "parentSpace" to all
    widgets together with additional machinery for getting/setting property
    values in this space (much like attr)(should be added as a mixin). I've got
    an implementation; let me know if you want it.
    Before looking at the implementation can you explain what this feature
    does? It sounds like you are saying that the children of a
    BorderContainer would be declared like:

    new dijit.layout.ContentPane({
    content: ...,
    parentSpace: {align: "left"}
    })

    or in markup

    <div dojoType="dijit.layout.ContentPane" parentSpace="align: 'left'">
    ....
    </div>

    Although that's less of a hack it is more typing/complexity for users.
    Not sure what the practical issue is with the current design?

    Of course could also just stick all those attributes into _Widget
    itself. That would eliminate the "hack" aspect, if that's what you find
    objectionable.
    3.
    Naming is often overly complex. To begin with, why is dijit._Widget marked
    with an underscore? Does dijit really intend to say, "this is subject to
    changes and don't count on it." Or even worse, "this is magic, and don't
    attempt to use it."
    Right, as I mentioned in my original mail I was thinking of renaming it
    _Widget to WidgetBase. The reason _Widget and _Templated each have an
    underscore now is to indicate that they are not widgets, but rather just
    a base class and a mixin, respectively. I can see how it's confusing
    though.
    There are many places where the leading underscore hedge is used. For
    example, dijit.focus has the objects _curFocus, _prevFocus, and
    _activeStack-all highly useful. These and others should be published for the
    world to see how great dijit really is. Sure.
    It seems to me that there is confusion between module namespaces, JavaScript
    filenames, and widget names. These are all different things. While the code
    decomposition seems quite reasonable, the assigning of widget names does
    not. For example, dijit has widgets named dijit.form.Checkbox and
    dijit.layout.BorderContainer-which begs the questions "are there so many
    widgets that this division is necessary?" And, "is there any chance of
    confusing a checkbox from a border container?" It would be quite simple to
    put each widget constructor as a property of dijit (e.g., dijit.Checkbox,
    dijit.BorderContainer), and this could be done without reorg of any existing
    code. This would be easier to understand for novices and easier to type for
    all.
    Well, collapsing the namespace definitely makes things easier to type.
    Not sure if it's easier to understand for novices... now we can tell
    beginners that "each widget in dijit.form has a single value", and "all
    the widgets in dijit.layout are meant to be formed into a hierarchy".

    It's not that the division is necessary, but that it makes things clearer.

    I don't have a strong feeling on it one way or the other though, I could
    be swayed if everyone feels it should be collapsed.
    I know I'll probably get yelled at for suggesting this...but, why do classes
    have to start with a cap!? What does it gain? Nothing else is leading cap'd.
    It's to denote that they are classes. As you pointed out, nothing else
    is leading capped, so this differentiates classes from plain modules
    like dijit.layout.

    Is there a reason to not do that?
    In short, I would suggest: eliminate as many underscore prefixed names as
    possible, shorten names as much as possible, and get rid of the leading cap
    (ducking).

    4.
    The capability to mix and match different capabilities (traits) into a
    widget at the time of construction rather than at the time of class
    definition. For example, the FormValueWidget undo machinery supports a very
    limited undo model that gets in the way of a more substantial undo model
    (e.g. a model that maintains a session undo stack). In some places dijit
    rolls these little nuggets of functionality into the class even though they
    are largely orthogonal to the real purpose of the class. These nuggets add
    complexity if you don't need them and make more work if you're doing
    something completely different. (Of course the counter argument is...if you
    do need them, they decrease complexity.)

    Another, perhaps better approach would be to specify the instance
    capabilities at construction time. For example, I may want a validating text
    box that binds to a specialized data source and uses a session-wide undo
    stack for one purpose and also want a validating text box, not bound to
    anything, with the current widget-level undo machinery for another purpose.
    Designing such a capability would probably require a bit of work on
    dojo.declare. If you have interest in this let me know and I'll try to work
    together a prototype.
    Yes, definitely interested.

    Someone in the meeting on Wednesday (maybe Dustin) was mentioning
    something that reminds me of what you were saying... about maybe having
    to move beyond mixins and have some kind of plugin model. Of course we
    can't really know if it's a great plan or impossible until we try it, so
    I'd be happy to see whatever you come up with.

    5.
    Mouse capture machinery should be factored out of existing code and
    published. I'm pretty sure Eugene has it in DnD, you've got some in
    BorderContainer, and I've built generic/cross-browser capture machinery for
    my stuff (let me know if you want it).
    You'll need to explain that more. Mouse capture like onclick handling?

    DnD publishes events (not mouse clicks, but higher level events) because
    of the nature of DnD, that once a user starts a drag it could be going
    anywhere. I'm not sure what we get by publishing events on widgets?

    6.
    Seems like the events in dijit.focus should be connected using dojo.connect
    and the event objects should be passed to the handlers.
    Hmm, not sure what you mean. Are you talking about the
    _onFocus()/_onBlur() magic callbacks for widgets? Where would the
    dojo.connect() calls be, in focus.js or in the individual widgets (or
    somewhere else)?
    7.
    There is no accelerator key machinery. I've got some; happy to contribute.
    Great, that would be a good contribution to dijit.
    8.
    In many places the code contains _local_ "var d= dojo". Consider
    constructing each module with the following pattern:

    (function() {
    var
    d= dojo,
    thisModule= d.provide("dijit.some.module");

    //module contents goes here
    //you can use d for dojo everywhere to your hearts content

    })();

    Notice that this pattern allows easily adding objects to the module
    namespace ("thisModule" gets optimized down to 2 characters with
    shrinksafe). If this pattern is pervasive, using "d" for dojo results in no
    obfuscation. I know this has been discussed elsewhere; not sure I ever
    understood a conclusion to that discussion.
    Well, I still consider it obfuscated. And note that this actually
    increases the size of the compressed (mod_deflate'd) files.


    As for "thisModule", doesn't that typically only occur once anyway? I
    guess this goes back to your suggestion to define a lot of functions
    outside the classes, although when we are doing that we typically do
    something like:

    dojo.mixin(dojo.html, {
    set: function(){ ... }
    get: function(){ ... }
    });


    9.
    I'm not totally convinced of the design of
    dijit._contained/dijit._container. It seems like they are reflecting the DOM
    tree into the widget tree, but the trees may in fact be far from 1-to-1,
    onto. Consider an alternative design where container just maintains an array
    of children. This has some advantages: children need not precisely reflect
    the DOM tree, children need not be instantiated (or can be lazy
    instantiated); fast retrieval along several axes; very simple traversal
    (startup, destroy, apply) routines. I admit that my use cases could be quite
    different than what _container was designed for...so my argument may be weak
    here.
    Could be. ContentPane is a more complex case of Container, in that the
    children are nested arbitrarily deeply. But it's also an example of
    why we don't keep an array of children, because developers might be
    mucking around with ContentPane.domNode directly and changing it at will.

    Of course, we could change that for 2.0, by disallowing mucking...

    10.
    _KeyNavContainer can't be easily (naturally) mixed in to _LayoutWidget.
    Seems like _KeyNavContainer should be a separate mixin. But I haven't
    investigated this deeply since _KeyNavContainer didn't meet my
    requirements. Let me know if you're interested in looking at something more
    substantial here (for _KeyNavContainer).
    I think the issue is that _KeyNavContainer is really a superclass of
    Container... it implements the same methods, like addChild() etc.

    But I'm open to prototyping a different class inheritance chain. I
    suppose it's straight forward to make _KeyNavContainer not extend
    container, and then tell people to mixin both _Container and
    _KeyNavContainer, assuming all the this.inherited() stuff still works.

    Again, if you want to prototype something that would be great. Since we
    did name these classes with underscores we could change the hierarchy
    now without breaking our contract.

    11.
    It's been said elsewhere...the style sheets always need work. This seems to
    be a black art sometimes.
    Sure, although that's a pretty vague description. I think we need work
    on making things prettier, but also probably refactoring of class names
    etc. to make a more solid foundation to build on.
  • Rawld Gill at Jan 25, 2009 at 3:27 pm
    Hi Bill,

    [Apologies to all for opening such an obnoxiously long discussion!]

    Since we've started talking about a lot of stuff here and since you are open
    to discussing some of my ideas (thanks!), and since both of us are really
    busy, I suggest we try to discuss the more major ideas one at a time. Some
    of the minor stuff doesn't require much more discussion. I've indicated both
    cases below.

    As a precursor to all of this--maybe really the first "major" idea--I'd like
    to share a little philosophy that I think is important to making dojo
    (indeed any software) optimal.

    The most important quality of any piece of software is that it does what it
    is supposed to do. Let's take this as an entry point even though I know
    there could be a long discussion over this statement.

    The most important single (but certainly no only) determiner of whether or
    not a piece of software will do what it's supposed to do is the degree of
    conceptual integrity that software possesses.

    One of the simplest heuristics to adjudicate conceptual integrity is to ask
    the question "does this software look like it was written by one person?"
    Yes implies high conceptual integrity, and conversely. (Dojo has addressed
    this in one very important way: three specific project leads --you, Pete,
    and Adam. Also, the 0.9 reorg was a great move towards conceptual
    integrity.)

    So, some of my suggestions that may seem frivolous were likely generated by
    the feeling that the code/pattern in question looks "out of place"...like
    someone else wrote it...with respect to the code/pattern otherwise in
    general use. And it is my belief that the software will be
    better--measurably in bugs, maintainability, usability, extendibility, not
    just cosmetically--if these areas are cleaned up.

    I'm happy to discuss these views on- or off-line with anybody listening who
    wants to have that discussion.

    Rawld Gill wrote:
    1.
    There is a tendency to try to stuff everything into a class. Sometimes this
    has two bad side effects: (1) decreased availability of an otherwise
    generally useful function and
    I wouldn't mind pulling out any methods you think developers want to
    call directly (maybe you can even supply a patch for this or we could
    work on it together). Would have to figure out what signature makes
    sense for each function, of course, for setStateClass maybe something
    like setStateClass(flags, domNode).
    Great! I'll propose a list under a separate discussion thread.
    An example of [2] is dijit._Widget._attrPairNames/_getAttrNames. At best
    these are so-called class-methods (static in C++), not instance methods. I
    really think they ought to be completely out of the class hierarchy and live
    as module functions.
    Your argument is that putting these static methods into the class is
    "increased complexity". Hmm, perhaps. It's a bit philosophical. Are
    class methods always bad? The idea was to hide_getAttrNames since it's
    just a helper for attr().
    Consider the hidden function getAttrReg in dijit/_Widget.js compared to the
    bedlump function dijit._Widget._getAttrNames also in dijit/_Widget.js. Both
    of these functions implement name caches. Why are they implemented
    differently? I strongly prefer getAttrReg implementation because the
    _getAttrNames cache has nothing to do with making a _Widget a _Widget...it's
    just a supporting utility function. If JavaScript had truly private symbol
    space within classes, I wouldn't object so much. But it doesn't.

    Even more general, consider the class dijit.WidgetSet that turns out to be
    used as a singleton on the variable dijit.registry. This, also, is basically
    a name cache.

    Really all of these things are implementing little namespaces. There are
    probably others as well (e.g., dojo._loadedModules). Why not implement a
    single bit of machinery (much like dijit.WidgetSet) that takes care of
    dijit.registry, getAttrReg, _getAttrNames, and others that we haven't
    thought about? If interested, I'll write it and send it to you. Let me know.

    Are class methods always bad?
    I think they are fine, but should be in the proper namespace. Unfortunately
    this implies they are properties of the constructor function in JavaScript.
    And writing (e.g.) dijit._Widget.getAttrNames is pretty ugly. So I don't
    have a firm opinion here.

    But private methods should be out of the class and implemented in the
    enclosing function literal (like getAttrReg).

    Also, to the maximum extent possible, if a method doesn't contribute to the
    character of a class, then it shouldn't be in the class. Little utility
    functions are examples of this.

    Let me know what you (or others) think of these arguments (I know they're
    just my opinions and not some gospel :). If there's the interest, I could
    propose a list of refactorings.
    2.
    The hack where BorderContainer extends all widgets with the properties
    region, splitter, etc. identifies the general problem of parent widgets
    desiring to keep child-dependent properties in their children. This problem
    can be solved in a general way by adding the property "parentSpace" to all
    widgets together with additional machinery for getting/setting property
    values in this space (much like attr)(should be added as a mixin). I've got
    an implementation; let me know if you want it.
    Before looking at the implementation can you explain what this feature
    does? It sounds like you are saying that the children of a
    BorderContainer would be declared like:

    new dijit.layout.ContentPane({
    content: ...,
    parentSpace: {align: "left"}
    })

    or in markup

    <div dojoType="dijit.layout.ContentPane" parentSpace="align: 'left'">
    ....
    </div>
    Yes, that's one way. Or dijit.layout.ContentPane could do something like:

    parentSpace.align= this.align;
    delete this.align;

    in postMixinProperties.
    Although that's less of a hack it is more typing/complexity for users.
    Not sure what the practical issue is with the current design?

    Of course could also just stick all those attributes into _Widget
    itself. That would eliminate the "hack" aspect, if that's what you find
    objectionable.
    As you probably know, I'm building a framework for building "traditional"
    applications using the browser as the platform. These apps are all
    envisioned as single-page apps with _very little or no_ markup. Although I'm
    still building experience with this stuff, I've found that (1) dijit
    components tend to get more complex and (2) parents tend to want to maintain
    state information about their children. (2) is easily solved by just jamming
    info into the child object. But I'm concerned about namespace clashes
    because of (1). That is, how does some random parent _know_ that it can use
    property "blaBla" in some random, possibly complex child without stepping on
    the child's property "blaBla".

    I solved the problem by implementing a mixin class that stores properties or
    functions that the parent owns at the child property "parentSpace". It's
    implemented much like dijit's _get/set<name>Attr (which I think is very
    cool!).

    All of this is probably not too relevant to many classes of apps and I'm not
    sure it's worth putting into dijit. I throw the idea out for feedback.

    3.
    Naming is often overly complex..
    Well, collapsing the namespace definitely makes things easier to type.
    Not sure if it's easier to understand for novices... now we can tell
    beginners that "each widget in dijit.form has a single value", and "all
    the widgets in dijit.layout are meant to be formed into a hierarchy".

    It's not that the division is necessary, but that it makes things clearer.
    I'm just not convinced of this. How does knowing that dijit.form.Textbox
    returns a single value help you? Is there a dijit.somethingElse.Textbox"
    that returns more than one value? What does it mean to be formed into a
    hierarchy? Is knowing this enough to use the competent? Is there a danger of
    using dijit.somethingElse.borderContainer that's not a hierarchy?

    I've rx'd some feedback from readers of the book that one of the pet peeves
    about dojo is the namespace issues. It just seems that dijit.Textbox,
    dijit.This, dijit.That, is so much cleaner.

    ...but...I know this is just my opinion. What do you think about opening
    this up as a topic under a separate thread and getting community feedback?
    I know I'll probably get yelled at for suggesting this...but, why do classes
    have to start with a cap!? What does it gain? Nothing else is leading
    cap'd.

    It's to denote that they are classes. As you pointed out, nothing else
    is leading capped, so this differentiates classes from plain modules
    like dijit.layout.

    Is there a reason to not do that?
    Is there a reason to do it? How does it help? If this style was dropped,
    then names are all written camel case, starting with a lowercase...and there
    is no "except for classes which are..." exception.

    But, I know this is religion. I'll drop it unless you or others want to
    discuss more.
    4.
    The capability to mix and match different capabilities (traits) into a
    widget at the time of construction rather than at the time of class
    definition.
    Yes, definitely interested.

    Someone in the meeting on Wednesday (maybe Dustin) was mentioning
    something that reminds me of what you were saying... about maybe having
    to move beyond mixins and have some kind of plugin model. Of course we
    can't really know if it's a great plan or impossible until we try it, so
    I'd be happy to see whatever you come up with.
    I've been playing with some prototypes to solve this problem. I also find
    that I'm always fighting dojo.declare and hope to solve both problems at the
    same time (btw...I'm not dissing dojo.declare. It's one of my favorite
    pieces of code in dojo, but I think it can be better yet).
    5.
    Mouse capture machinery should be factored out of existing code and
    published. I'm pretty sure Eugene has it in DnD, you've got some in
    BorderContainer, and I've built generic/cross-browser capture machinery for
    my stuff (let me know if you want it).
    You'll need to explain that more.
    In order to implement robust dragging, you need to capture the mouse. In IE
    you call element.setCapture; all others you need to set the 3rd argument to
    addEventLister to true--something you can't do with dojo.connect. I've got
    machinery that does this so you can write:

    baf.capture.capture({
    mousemove: function(e) {
    //stuff to do on mouse move
    },
    mouseup: function(e) {
    //stuff to do on mouse up
    },
    //also can add other handlers like blur, click,
    });

    Now, all mouse events go to these functions--_first and only_.
    From within these functions you can call baf.capture.release() to take down
    the machinery. The machinery automatically disengages upon a blur event.

    This makes implementing dragging pretty simple. I need to look carefully at
    what Eugene is doing in DnD. Also, I don't totally understand the purpose of
    this.cover in dijit.layout._Splitter. But once understood, we should be able
    to put together something like the above that will work in all cases,
    perhaps simplifying and shortening code.

    Is this worth a separate thread?
    6.
    Seems like the events in dijit.focus should be connected using
    dojo.connect
    and the event objects should be passed to the handlers.
    Hmm, not sure what you mean. Are you talking about the
    _onFocus()/_onBlur() magic callbacks for widgets? Where would the
    dojo.connect() calls be, in focus.js or in the individual widgets (or
    somewhere else)?
    I talking about the event connections in dijit.registerWin in
    dijit/_base/focus.js. Why aren't these using dojo.connect? Why aren't they
    passing the event objects in the _onFocus/_onBlur handlers when the stack is
    traversed in _setStack.

    Btw, the reason I needed the event objects was I wanted to know who was
    losing and gaining focus. But I found that I could get this info by looking
    at dijit._activeStack. So, perhaps the event objects aren't really
    necessary. But...is there a reason to not pass them on? The connecting code
    doesn't have to look at them.
    7.
    There is no accelerator key machinery. I've got some; happy to
    contribute.

    Great, that would be a good contribution to dijit.
    I'll open a separate thread.
    8.
    In many places the code contains _local_ "var d= dojo". Consider
    constructing each module with the following pattern:

    (function() {
    var
    d= dojo,
    thisModule= d.provide("dijit.some.module");

    //module contents goes here
    //you can use d for dojo everywhere to your hearts content

    })();

    Notice that this pattern allows easily adding objects to the module
    namespace ("thisModule" gets optimized down to 2 characters with
    shrinksafe). If this pattern is pervasive, using "d" for dojo results in no
    obfuscation. I know this has been discussed elsewhere; not sure I ever
    understood a conclusion to that discussion.
    Well, I still consider it obfuscated. And note that this actually
    increases the size of the compressed (mod_deflate'd) files.


    As for "thisModule", doesn't that typically only occur once anyway? I
    guess this goes back to your suggestion to define a lot of functions
    outside the classes, although when we are doing that we typically do
    something like:

    dojo.mixin(dojo.html, {
    set: function(){ ... }
    get: function(){ ... }
    });
    This starts to be religion quickly. Here are some counter points:

    1. It seems like the toolkit should either always or never use d= dojo.
    That's the real point.

    2. I like d= dojo because I get tired of typing dojo. Since I start every
    module like this, it's not obfuscation to me. I think I've got at least Pete
    on my side on this one.

    3. I saw your study on mod_deflate. Nice work. It's always surprising when
    this happens. But I don't think using/not using the d= dojo idiom should
    affect size on the wire substantially. I certainly would not advocate using
    the idiom solely to shorten transfer size (particularly because...it
    apparently doesn't!).

    4. I'm not a fan of the dojo.mixin(moduleObject, ...) idiom. It adds a level
    of nesting that, to me, is obfuscation. It probably doesn't help with
    parsing tools that analyze the code (pull documentation, etc.) To me,
    thisModule.someFunction= function(... is much clearer.

    Unless others would like to engage this discussion, I'll drop it.
    9.
    I'm not totally convinced of the design of
    dijit._contained/dijit._container. It seems like they are reflecting the DOM
    tree into the widget tree, but the trees may in fact be far from 1-to-1,
    onto. Consider an alternative design where container just maintains an array
    of children. This has some advantages: children need not precisely reflect
    the DOM tree, children need not be instantiated (or can be lazy
    instantiated); fast retrieval along several axes; very simple traversal
    (startup, destroy, apply) routines. I admit that my use cases could be quite
    different than what _container was designed for...so my argument may be weak
    here.
    Could be. ContentPane is a more complex case of Container, in that the
    children are nested arbitrarily deeply. But it's also an example of
    why we don't keep an array of children, because developers might be
    mucking around with ContentPane.domNode directly and changing it at will.

    Of course, we could change that for 2.0, by disallowing mucking...
    I'll send you more thoughts on this as I get more experience with the
    framework I'm building.
    10.
    _KeyNavContainer can't be easily (naturally) mixed in to _LayoutWidget.
    Seems like _KeyNavContainer should be a separate mixin. But I haven't
    investigated this deeply since _KeyNavContainer didn't meet my
    requirements. Let me know if you're interested in looking at something more
    substantial here (for _KeyNavContainer).
    I think the issue is that _KeyNavContainer is really a superclass of
    Container... it implements the same methods, like addChild() etc.

    But I'm open to prototyping a different class inheritance chain. I
    suppose it's straight forward to make _KeyNavContainer not extend
    container, and then tell people to mixin both _Container and
    _KeyNavContainer, assuming all the this.inherited() stuff still works.

    Again, if you want to prototype something that would be great. Since we
    did name these classes with underscores we could change the hierarchy
    now without breaking our contract.
    I'll open another thread on this after the framework's first release (soon,
    I hope).
    11.
    It's been said elsewhere...the style sheets always need work. This seems to
    be a black art sometimes.
    Just meant to say...I'm not great at this. But I always appreciate the art
    of others.
  • Sam foster at Jan 26, 2009 at 5:15 am
    yes to seperate threads to the more substantial topics here.
    Some comment inline on the less...
    The most important single (but certainly no only) determiner of whether or
    not a piece of software will do what it's supposed to do is the degree of
    conceptual integrity that software possesses.
    this smacks a little of navel gazing. But yes it may be a factor in
    the intangible feeling that people try and express about dojo v.s
    jquery vs ext etc. I've always thought php was scrappy, I can commit
    any of the method signatures to memory and dislike working with it
    partly as a result. We hear time and again the jquery is just more
    "fun" to work with. So I cant discount this as something we need to
    give effort to.
    I wouldn't mind pulling out any methods you think developers want to
    call directly (maybe you can even supply a patch for this or we could
    work on it together). Would have to figure out what signature makes
    sense for each function, of course, for setStateClass maybe something
    like setStateClass(flags, domNode).
    Ditto here. I was my main motivation for creating dojo.html.set /
    dojox.html.set, and there's lots more of it to do. As I hack I can
    borrow things from a class' prototype, but where a useful helper
    function is made private, or entangled in arbirary specifics of the
    host class you have no choice but to copy/paste.

    Really all of these things are implementing little namespaces. There are
    probably others as well (e.g., dojo._loadedModules). Why not implement a
    single bit of machinery (much like dijit.WidgetSet) that takes care of
    dijit.registry, getAttrReg, _getAttrNames, and others that we haven't
    thought about? If interested, I'll write it and send it to you. Let me know.
    I'd be interested in this, I agree this is all over, and a facility
    needed not just within the toolkit itself, but by developers working
    on top of it. Its most explict in the dojox.storage api where there
    are getters and setters with an optional namespace. That might provide
    the basis for a toolkit wide cached property api.
    Are class methods always bad?
    I think they are fine, but should be in the proper namespace. Unfortunately
    this implies they are properties of the constructor function in JavaScript.
    And writing (e.g.) dijit._Widget.getAttrNames is pretty ugly. So I don't
    have a firm opinion here.
    I find class methods a bit weird in javascript. I use them
    occasionally mostly for implementing singletons, factory methods
    (getInstance/createInstance etc.). But its rare you need a class
    method vs. a package/namespaced methods.

    Also, to the maximum extent possible, if a method doesn't contribute to the
    character of a class, then it shouldn't be in the class. Little utility
    functions are examples of this.
    amen brother :)
    Naming is often overly complex..
    I'm thumbs down on this. For sure this was true up to 0.9. I do think
    we should be clear what the namespace is for, it should not just be a
    sub-project for particular contributors stuff. That might mean
    ensuring that modules under a namespace implement a consistent
    interface. So everything under dijit.form really implements the
    dijit._FormWidget "interface". That's the implied contract of the
    namespace it seems. But ther'es potentially utilities etc. that are
    only relevant for form / layout / foo widgets, and they need a place
    to live
    I know I'll probably get yelled at for suggesting this...but, why do classes
    have to start with a cap!? What does it gain? Nothing else is leading
    cap'd.

    It's to denote that they are classes. As you pointed out, nothing else
    is leading capped, so this differentiates classes from plain modules
    like dijit.layout.
    Yeah, why fix what aint broke? Its been one of the least contentious
    issues in the styleguide. Classes are capitalized. The only place this
    gets blurry is when you are defining prototypes and using
    dojo.delegate. We dont have any way to denote those as "special"
    objects, (maybe they are not special and that's the point)

    4.
    The capability to mix and match different capabilities (traits) into a
    widget at the time of construction rather than at the time of class
    definition.
    Yes, spare me from the tyranny of rigid class heirachies! Please, I'd
    love to see your ideas here. I was the one mumbling vaguely about
    getting beyond mixins in the dojo-meeting. Part of my motivation and
    experience with this has been in trying to break up large monolithic
    classes for readability. One example is the *Panes. A content pane is
    fundamentially a managed dom element that has stuff in it. It has some
    potential behaviors and functionality that might be strapped on (or
    preconfigured for sane defaults)
    * It might be configured to load remote content.
    * You need to be able to safely set/remove/append content on it.
    * It might need loading and transition behaviour.
    * It need to be able to exist as a child in a layout

    So, loading content isnt the exclusive domain of a content pane.
    Arguably pretty much any widget should be able to lazy-load its guts
    and have them dynamically swapped out.
    Adding/removing/setting content - might mean different things in
    different contexts. For a content pane it likely means html (but could
    be a dict with a template to render it). For a layout widget, it might
    take a structure and pass off bits to its children to load. For a
    menu, its populating the dropdown. etc. But there should be a
    consistent api for it
    * Likewise loading and transitioning. At a conceptual level, any
    widget can be in a loading state, some widgets might choose to
    represent that with some on-screen thing. That loading thing *must* be
    overridable without having to subclass - it varies by application,
    project, widget context, etc.
    * this email is getting to long.

    The same goes for widgets that take user input Indicating an error
    state needs to be easily pluggable ideally.

    As for "thisModule", doesn't that typically only occur once anyway? I
    guess this goes back to your suggestion to define a lot of functions
    outside the classes, although when we are doing that we typically do
    something like:

    dojo.mixin(dojo.html, {
    set: function(){ ... }
    get: function(){ ... }
    });
    I played with a code template that went like this:
    (function(ns) {
    dojo.declare(ns, [supers], {

    });

    }("myNamespace")

    Its a nice way to define package "globals". But ultimately probably
    more confusing than helpful, as you have to scan to the bottom of the
    file to see what these things are. in a rhino/cmd-line context, you
    can do:
    (function(packageName, scriptArgs) {

    })("my.namespace", "samiam.parserGenerator",
    Array.prototype.slice.apply(arguments))

    11.
    It's been said elsewhere...the style sheets always need work. This seems to
    be a black art sometimes.
    Not sometimes :) Things have improved a lot since we nonken joined us,
    and the post 1.0 push. But its still some work away. I think we've
    reached a threshold where we've got about as far as we can with a
    developer-first approach. The last 10% will only come from working to
    a well thought out design, and designers applying the thumbscrews to
    make it happen. The couple designers I've talked to about this found
    it a daunting task though - designing for a toolkit is much more
    difficult than a one-off application, as there are so many variables.
    Its not something they wanted to commit to on a volunteer basis.
    Still, even just a couple blue-sky comps that gave us a refined visual
    language to work towards would be a help. Certainly things like
    getting the form widgets to align is a long-standing issue that needs
    resolution. Some test pages would be a start there. If we had some
    built-out form pages, we could give those to a designer and get back
    recommendations to "fix" them. Dijit as a whole has improved I think
    since the creation of the themeTester (shout-out to phiggins), we need
    more of that where we can see the widgets in context.

    thanks for the thoughts Rawld,
    /Sam
  • Bill Keese at Jan 28, 2009 at 7:41 am
    Rawld,

    This is all good stuff. As you suggested please split off these
    discussions to separate threads, perhaps after prototyping a solution,
    so we have something more concrete to discuss.

    Oh... most of your suggestions aren't tied to 2.0, so whatever can be
    done ahead of 2.0 (i.e. doesn't require branching the code), we should
    do those things first.
    Really all of these things are implementing little namespaces. There are
    probably others as well (e.g., dojo._loadedModules). Why not implement a
    single bit of machinery (much like dijit.WidgetSet) that takes care of
    dijit.registry, getAttrReg, _getAttrNames, and others that we haven't
    thought about? If interested, I'll write it and send it to you. Let me know.
    Sure, that would be great.

    Also, to the maximum extent possible, if a method doesn't contribute to the
    character of a class, then it shouldn't be in the class. Little utility
    functions are examples of this.

    Let me know what you (or others) think of these arguments (I know they're
    just my opinions and not some gospel :). If there's the interest, I could
    propose a list of refactorings.
    Sure, a solid proposal would be worth looking at. You'll have to think
    about how the namespacing works though, i.e. what files those utility
    functions go in and what their fully qualified names are.


    I've rx'd some feedback from readers of the book that one of the pet peeves
    about dojo is the namespace issues. It just seems that dijit.Textbox,
    dijit.This, dijit.That, is so much cleaner.

    ...but...I know this is just my opinion. What do you think about opening
    this up as a topic under a separate thread and getting community feedback?
    Well, I can't argue against getting community feedback. I guess that
    would have to be in the dojo interest forum.

    5.
    Mouse capture machinery should be factored out of existing code and
    published. I'm pretty sure Eugene has it in DnD, you've got some in
    BorderContainer, and I've built generic/cross-browser capture machinery for
    my stuff (let me know if you want it).
    You'll need to explain that more.
    In order to implement robust dragging, you need to capture the mouse. In IE
    you call element.setCapture; all others you need to set the 3rd argument to
    addEventLister to true--something you can't do with dojo.connect. I've got
    machinery that does this so you can write:

    baf.capture.capture({
    mousemove: function(e) {
    //stuff to do on mouse move
    },
    mouseup: function(e) {
    //stuff to do on mouse up
    },
    //also can add other handlers like blur, click,
    });

    Now, all mouse events go to these functions--_first and only_.
    From within these functions you can call baf.capture.release() to take down
    the machinery. The machinery automatically disengages upon a blur event.

    This makes implementing dragging pretty simple. I need to look carefully at
    what Eugene is doing in DnD. Also, I don't totally understand the purpose of
    this.cover in dijit.layout._Splitter. But once understood, we should be able
    to put together something like the above that will work in all cases,
    perhaps simplifying and shortening code.

    Is this worth a separate thread?
    Perhaps. I still don't understand what problem you are trying to solve.
    In any case, if you want to continue discussion then yes, please
    start a separate thread.

    6.
    Seems like the events in dijit.focus should be connected using
    dojo.connect
    and the event objects should be passed to the handlers.
    Hmm, not sure what you mean. Are you talking about the
    _onFocus()/_onBlur() magic callbacks for widgets? Where would the
    dojo.connect() calls be, in focus.js or in the individual widgets (or
    somewhere else)?
    I talking about the event connections in dijit.registerWin in
    dijit/_base/focus.js. Why aren't these using dojo.connect?
    IIRC it's because dojo.connect(<body>, "onblur", ...) won't catch blur
    events on descendant nodes. Blur and focus events don't bubble through
    via standard dojo.connect
    Why aren't they
    passing the event objects in the _onFocus/_onBlur handlers when the stack is
    traversed in _setStack.
    Maybe because a so-called _onFocus() event could be caused by actually
    focusing on a node, or by clicking a non-focusable node, like the arrow
    keys of a spinner... it's more of a higher level conceptual event (like
    onDragStart).
  • Mike Wilson at Jan 24, 2009 at 3:57 pm

    Rawld Gill wrote:
    2.
    The hack where BorderContainer extends all widgets with the properties
    region, splitter, etc. identifies the general problem of
    parent widgets
    desiring to keep child-dependent properties in their
    children. This problem
    can be solved in a general way by adding the property
    "parentSpace" to all
    widgets together with additional machinery for
    getting/setting property
    values in this space
    FWIW, in the X11 (Xt Intrinsics) world these kinds of parent-
    managed properties are called "constraints".

    The idea there is that a widget defines a structure with the
    constraint properties, much like it does for its own
    properties, f ex:
    {
    allowResize: false,
    allowMove: true
    }
    and the widget system then automatically adds these properties
    to all direct children of the widget.

    The name "constraints" comes from the fact that these props are
    often used for specifying layout information on children of
    layout widgets, and thus constrain how the layout widget is
    allowed to change the respective child's geometry.
    When setting properties on a child you can then specify values
    for these added properties.

    Best regards
    Mike
  • Alex Russell at Jan 28, 2009 at 2:17 pm
    Hey all:

    My biggest wish is for real getters and setters. This constrains us to
    IE 8+ (other browsers don't suck nearly as much), but if we're gonna
    target the "real future", we could go a very long way toward a faster,
    easier-to-understand system if we could start to melt away more of the
    conceptual overhead of the _Widget class. That's perhaps the most
    controversial thing I'll suggest, and I'm relatively sure that i'll
    get shot down on it. If, OTOH, we do go this route, it would give Core
    the freedom to be similiarly unconstrained and would allow, e.g., the
    Data APIs to become MUCH more natural than they are today.

    Also on my (plumbing) wishlist is a system for parameterizing theme
    CSS. I'll leave it to those handling themes to think more about this,
    but we pay a big price for our current system in several ways:

    1.) descendant selectors slow down application of widget CSS to a
    huge degree
    2.) we always send all the CSS for every browser *to* every browser.
    The build system does not differentiate/trim/generate different
    versions for different browsers despite our CSS workarounds for IE
    being a gigantic proportion of the overall size.
    3.) themes that specialize rely on cascade order for over-rides even
    when "built". This balloons the # and size of the rules, creating a
    lot of rule chaff that again slows down application of styles for
    widgets. Having a better parameterization system might allow us to
    generate better theme-specific .css files
    4.) themes are hard to parameterize because as a result of all of the
    above. The explosion of rules to deal with IE-isms really makes it
    hard for theme authors or tools to easily parameterize what makes one
    theme different from another. I hate suggesting a runtime pre-
    processor for CSS with a build-time equivalent, but it really does
    seem like the best path forward.

    I should re-itereate that our current system rocks. It's pretty easy
    to work with, theme inheritance is understandable, and theme
    application Just Works (TM). All of my suggestions here are not meant
    as criticisms in any way, but rather things that a shiny future might
    hold assuming that browsers aren't going to beat us to things like CSS
    variables and expressions.

    We should also revisit dojo.declare() and its effect on widgets. The
    widget system pays a high cost for inefficiencies in declare(), and
    2.0 seems the right time to peel some of that back and clean it out.

    On the feature front, I'd like to see hbox/vbox implemented. Also,
    attachment (pre-constructed DOMs) should be supported out-of-the-box
    as a way to speed up systems like Dojango and ZF which could be made
    template-savvy and could therefore do much of the DOM generating heavy
    lifting for us. I think it's possible to back some of that in to the
    1.3-era APIs, but doing it pervasively and thinking about how the
    template system could better support that pattern is something that
    I'd like to see on the table for 2.0.

    For 2.0, we should make DTL the default template system for widgets
    and remove the direct string replacement syntax from _Templated (e.g.,
    ${somePropertyName}) since we pay a huge runtime cost for that feature
    in widgets that use it and a code cost to support it.

    Lastly, states and data-bound widgets. Many widgets manage states like
    "focused", "disabled", etc. These are common things across most Dijits
    and should be codified in common mixins and CSS styles to support
    them. Data bound widgets should share some minimal mixin API to help
    programmers better understand how to build data-backed widgets and how
    to use them more consistently.

    Obviously, I have something of a wishlist for Core 2.0 as well, but
    I'd like for the Dijit 2.0 stuff to inform those requirements.

    Regards

    On Jan 21, 2009, at 4:54 PM, Bill Keese wrote:

    A while back somebody asked about the road map for Dojo 2.0, and I
    finally gave some thought to dijit.

    There are lots of things people want for the future of dijit,
    documented
    (among other places) in:

    * http://dojotoolkit.org/2007/08/12/widget-wish-list
    * http://www.dojotoolkit.org/2007/11/21/widget-wish-list-response
    * http://www.dojotoolkit.org/2008/09/17/dijit-1-3
    * http://bugs.dojotoolkit.org/report/19

    Most of those tasks, though, could be done either before or after 2.0,
    so they don't need to be tied to the 2.0 release. What I'm looking at
    is the changes that require changes in back-compatibility.
    Specifically my thoughts are:


    General:

    * remove deprecated code (setValue(), etc.)
    * remove deprecated widgets (SplitContainer, LayoutContainer)
    * finish up file split by widget (Button.js and Checkbox.js remain)


    Rename files/classes/directories:

    * Textarea --> ResizableTextArea/AutoSizingTextArea (note case
    change).
    * SimpleTextarea --> TextArea (note case change)
    * _editor --> editor (since plugins aren't really private)
    * _tree --> tree (since dijit._tree.dndSource isn't private)
    * _Widget --> WidgetBase, _Templated --> TemplatedMixin (since they
    are not really private)
    * some (but not all) of these changes could be done now, with
    back-compat stubs


    Widget:

    * rename destroyRecursive() to destroy() and get rid of
    uninitialize()
    * move attributeMap to a mixin?


    Widget Attributes Schema/Parser changes:

    * require widgets to declare their public attributes (a.k.a.
    parameters) explicitly, along w/how to get the parameters from markup
    (from DOM node attributes or from innerHTML via CSS expression)

    * widgets no longer need to query srcNodeRef to get their more
    complex
    parameters

    * parser also has support for Container widgets; parser will call
    addChild() for each child, or maybe pass in a children[] array of
    widgets to the parent widget's constructor

    * parser stops at ContentPane; ContentPane will parse it's own
    content
    when it is displayed. ie, defer parsing of hidden panes in
    TabContainer.


    Widget Events:

    * Users call Widget.subscribe() or Widget.connect() method for
    monitoring events (like onClick) on a widget, rather than calling
    dojo.connect()
    * This removes the need for widgets to implement empty onClick() type
    functions
    * Not sure about documentation, I guess the events each widget
    supports would need to be listed in the widget description

    Themes and CSS:

    * if we want themes to be able to control non-CSS behavior (like
    animations), then we probably have to modify the way users specify the
    theme(s) for a page. Instead of setting <body class="tundra"> maybe
    the
    theme would be a djConfig variable, and to override a theme for a
    particular widget would require setting theme="soria" on that widget.

    * was it a mistake to remove templateCssPath in 1.0? I have to
    think
    about this some more, but anyway, 2.0 is a chance to change how we
    deal
    with CSS.

    TabContainer and friends:

    * remove topics from StackContainer? Can just use simple events.
    * remove StackController altogether? Probably no one is using it.
    * TabContainer implementation can be simplified by removing
    controller
    paradigm (which lets user can create a TabController separately from
    the
    TabContainer). Rather just combine into one widget.


    Build stage?

    * For theme generation (from template files) and possibly other
    things
    I wonder if it makes sense to require a build step. Obviously there
    are
    some disadvantages but I wonder if the pros outweigh the cons.
    Have to
    think about that one.
    * A build could also solve NLS issues such as locale file generation
    (right now a raw checkout only supports a few locales), plus the
    famous
    404 error trying to load language files that don't exist.


    Private / Protected / Public:

    * The _foo naming method doesn't work since it can't distinguish
    private from protected, and also since many of our protected methods
    don't have an underscore, like postCreate(). I guess though this is
    just a question of putting that metadata in comments, so this isn't a
    2.0 issue per se.


    Mixins (suggestion from dylan):

    * Make more things mixins. I was told recently that a11y and i18n
    should be mixins rather than requirements because some apps do not
    need
    them.



    Anyway, those are just some initial thoughts.

    Bill


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Eugene Lazutkin at Jan 28, 2009 at 3:07 pm
    What can I say? In my opinion Alex hit the bull's eye once again --- I
    am +1 on all his points. I started to comment on his proposals, but it
    turned out they are all in the "me too" category, or different arguments
    to the same effect.

    Obviously at some point we need to do a little prototyping to get a feel
    of new APIs and paradigms.

    Thanks,

    Eugene Lazutkin
    Dojo Toolkit, Committer
    SitePen, Developer

    PS: Waiting for the Core 2.0 discussion --- I do too have a wish list
    for it.

    PPS: I want to stress that we should not be afraid to propose
    server-side enhancements and standards. Like Alex said, the CSS
    pre-processor is one but very important example, especially in the light
    of the work I was doing at my work place lately. The pre-instantiation
    of widgets is the other low hanging fruit.


    Alex Russell wrote:
    Hey all:

    My biggest wish is for real getters and setters. This constrains us to
    IE 8+ (other browsers don't suck nearly as much), but if we're gonna
    target the "real future", we could go a very long way toward a faster,
    easier-to-understand system if we could start to melt away more of the
    conceptual overhead of the _Widget class. That's perhaps the most
    controversial thing I'll suggest, and I'm relatively sure that i'll
    get shot down on it. If, OTOH, we do go this route, it would give Core
    the freedom to be similiarly unconstrained and would allow, e.g., the
    Data APIs to become MUCH more natural than they are today.

    Also on my (plumbing) wishlist is a system for parameterizing theme
    CSS. I'll leave it to those handling themes to think more about this,
    but we pay a big price for our current system in several ways:

    1.) descendant selectors slow down application of widget CSS to a
    huge degree
    2.) we always send all the CSS for every browser *to* every browser.
    The build system does not differentiate/trim/generate different
    versions for different browsers despite our CSS workarounds for IE
    being a gigantic proportion of the overall size.
    3.) themes that specialize rely on cascade order for over-rides even
    when "built". This balloons the # and size of the rules, creating a
    lot of rule chaff that again slows down application of styles for
    widgets. Having a better parameterization system might allow us to
    generate better theme-specific .css files
    4.) themes are hard to parameterize because as a result of all of the
    above. The explosion of rules to deal with IE-isms really makes it
    hard for theme authors or tools to easily parameterize what makes one
    theme different from another. I hate suggesting a runtime pre-
    processor for CSS with a build-time equivalent, but it really does
    seem like the best path forward.

    I should re-itereate that our current system rocks. It's pretty easy
    to work with, theme inheritance is understandable, and theme
    application Just Works (TM). All of my suggestions here are not meant
    as criticisms in any way, but rather things that a shiny future might
    hold assuming that browsers aren't going to beat us to things like CSS
    variables and expressions.

    We should also revisit dojo.declare() and its effect on widgets. The
    widget system pays a high cost for inefficiencies in declare(), and
    2.0 seems the right time to peel some of that back and clean it out.

    On the feature front, I'd like to see hbox/vbox implemented. Also,
    attachment (pre-constructed DOMs) should be supported out-of-the-box
    as a way to speed up systems like Dojango and ZF which could be made
    template-savvy and could therefore do much of the DOM generating heavy
    lifting for us. I think it's possible to back some of that in to the
    1.3-era APIs, but doing it pervasively and thinking about how the
    template system could better support that pattern is something that
    I'd like to see on the table for 2.0.

    For 2.0, we should make DTL the default template system for widgets
    and remove the direct string replacement syntax from _Templated (e.g.,
    ${somePropertyName}) since we pay a huge runtime cost for that feature
    in widgets that use it and a code cost to support it.

    Lastly, states and data-bound widgets. Many widgets manage states like
    "focused", "disabled", etc. These are common things across most Dijits
    and should be codified in common mixins and CSS styles to support
    them. Data bound widgets should share some minimal mixin API to help
    programmers better understand how to build data-backed widgets and how
    to use them more consistently.

    Obviously, I have something of a wishlist for Core 2.0 as well, but
    I'd like for the Dijit 2.0 stuff to inform those requirements.

    Regards


    On Jan 21, 2009, at 4:54 PM, Bill Keese wrote:
    A while back somebody asked about the road map for Dojo 2.0, and I
    finally gave some thought to dijit.

    There are lots of things people want for the future of dijit,
    documented
    (among other places) in:

    * http://dojotoolkit.org/2007/08/12/widget-wish-list
    * http://www.dojotoolkit.org/2007/11/21/widget-wish-list-response
    * http://www.dojotoolkit.org/2008/09/17/dijit-1-3
    * http://bugs.dojotoolkit.org/report/19

    Most of those tasks, though, could be done either before or after 2.0,
    so they don't need to be tied to the 2.0 release. What I'm looking at
    is the changes that require changes in back-compatibility.
    Specifically my thoughts are:


    General:

    * remove deprecated code (setValue(), etc.)
    * remove deprecated widgets (SplitContainer, LayoutContainer)
    * finish up file split by widget (Button.js and Checkbox.js remain)


    Rename files/classes/directories:

    * Textarea --> ResizableTextArea/AutoSizingTextArea (note case
    change).
    * SimpleTextarea --> TextArea (note case change)
    * _editor --> editor (since plugins aren't really private)
    * _tree --> tree (since dijit._tree.dndSource isn't private)
    * _Widget --> WidgetBase, _Templated --> TemplatedMixin (since they
    are not really private)
    * some (but not all) of these changes could be done now, with
    back-compat stubs


    Widget:

    * rename destroyRecursive() to destroy() and get rid of
    uninitialize()
    * move attributeMap to a mixin?


    Widget Attributes Schema/Parser changes:

    * require widgets to declare their public attributes (a.k.a.
    parameters) explicitly, along w/how to get the parameters from markup
    (from DOM node attributes or from innerHTML via CSS expression)

    * widgets no longer need to query srcNodeRef to get their more
    complex
    parameters

    * parser also has support for Container widgets; parser will call
    addChild() for each child, or maybe pass in a children[] array of
    widgets to the parent widget's constructor

    * parser stops at ContentPane; ContentPane will parse it's own
    content
    when it is displayed. ie, defer parsing of hidden panes in
    TabContainer.


    Widget Events:

    * Users call Widget.subscribe() or Widget.connect() method for
    monitoring events (like onClick) on a widget, rather than calling
    dojo.connect()
    * This removes the need for widgets to implement empty onClick() type
    functions
    * Not sure about documentation, I guess the events each widget
    supports would need to be listed in the widget description

    Themes and CSS:

    * if we want themes to be able to control non-CSS behavior (like
    animations), then we probably have to modify the way users specify the
    theme(s) for a page. Instead of setting <body class="tundra"> maybe
    the
    theme would be a djConfig variable, and to override a theme for a
    particular widget would require setting theme="soria" on that widget.

    * was it a mistake to remove templateCssPath in 1.0? I have to
    think
    about this some more, but anyway, 2.0 is a chance to change how we
    deal
    with CSS.

    TabContainer and friends:

    * remove topics from StackContainer? Can just use simple events.
    * remove StackController altogether? Probably no one is using it.
    * TabContainer implementation can be simplified by removing
    controller
    paradigm (which lets user can create a TabController separately from
    the
    TabContainer). Rather just combine into one widget.


    Build stage?

    * For theme generation (from template files) and possibly other
    things
    I wonder if it makes sense to require a build step. Obviously there
    are
    some disadvantages but I wonder if the pros outweigh the cons.
    Have to
    think about that one.
    * A build could also solve NLS issues such as locale file generation
    (right now a raw checkout only supports a few locales), plus the
    famous
    404 error trying to load language files that don't exist.


    Private / Protected / Public:

    * The _foo naming method doesn't work since it can't distinguish
    private from protected, and also since many of our protected methods
    don't have an underscore, like postCreate(). I guess though this is
    just a question of putting that metadata in comments, so this isn't a
    2.0 issue per se.


    Mixins (suggestion from dylan):

    * Make more things mixins. I was told recently that a11y and i18n
    should be mixins rather than requirements because some apps do not
    need
    them.



    Anyway, those are just some initial thoughts.

    Bill


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Torrey Rice at Jan 28, 2009 at 3:44 pm
    I'll echo what Eugene said about what Alex said. What Alex said (in my
    not-as-technical as you guys opinion) is dead on.

    In a possibly unrelated note, I'm sure this has been talked about a bit
    but having a compat layer for jQuery UI (and maybe even EXT and YUI)
    would also be great. Perhaps an easy way to wrap these widgets so that
    they can masquerade as Dijits.

    -Torrey
    On 1/28/09 1:07 PM, Eugene Lazutkin wrote:
    What can I say? In my opinion Alex hit the bull's eye once again --- I
    am +1 on all his points. I started to comment on his proposals, but it
    turned out they are all in the "me too" category, or different arguments
    to the same effect.

    Obviously at some point we need to do a little prototyping to get a feel
    of new APIs and paradigms.

    Thanks,

    Eugene Lazutkin
    Dojo Toolkit, Committer
    SitePen, Developer

    PS: Waiting for the Core 2.0 discussion --- I do too have a wish list
    for it.

    PPS: I want to stress that we should not be afraid to propose
    server-side enhancements and standards. Like Alex said, the CSS
    pre-processor is one but very important example, especially in the light
    of the work I was doing at my work place lately. The pre-instantiation
    of widgets is the other low hanging fruit.


    Alex Russell wrote:
    Hey all:

    My biggest wish is for real getters and setters. This constrains us to
    IE 8+ (other browsers don't suck nearly as much), but if we're gonna
    target the "real future", we could go a very long way toward a faster,
    easier-to-understand system if we could start to melt away more of the
    conceptual overhead of the _Widget class. That's perhaps the most
    controversial thing I'll suggest, and I'm relatively sure that i'll
    get shot down on it. If, OTOH, we do go this route, it would give Core
    the freedom to be similiarly unconstrained and would allow, e.g., the
    Data APIs to become MUCH more natural than they are today.

    Also on my (plumbing) wishlist is a system for parameterizing theme
    CSS. I'll leave it to those handling themes to think more about this,
    but we pay a big price for our current system in several ways:

    1.) descendant selectors slow down application of widget CSS to a
    huge degree
    2.) we always send all the CSS for every browser *to* every browser.
    The build system does not differentiate/trim/generate different
    versions for different browsers despite our CSS workarounds for IE
    being a gigantic proportion of the overall size.
    3.) themes that specialize rely on cascade order for over-rides even
    when "built". This balloons the # and size of the rules, creating a
    lot of rule chaff that again slows down application of styles for
    widgets. Having a better parameterization system might allow us to
    generate better theme-specific .css files
    4.) themes are hard to parameterize because as a result of all of the
    above. The explosion of rules to deal with IE-isms really makes it
    hard for theme authors or tools to easily parameterize what makes one
    theme different from another. I hate suggesting a runtime pre-
    processor for CSS with a build-time equivalent, but it really does
    seem like the best path forward.

    I should re-itereate that our current system rocks. It's pretty easy
    to work with, theme inheritance is understandable, and theme
    application Just Works (TM). All of my suggestions here are not meant
    as criticisms in any way, but rather things that a shiny future might
    hold assuming that browsers aren't going to beat us to things like CSS
    variables and expressions.

    We should also revisit dojo.declare() and its effect on widgets. The
    widget system pays a high cost for inefficiencies in declare(), and
    2.0 seems the right time to peel some of that back and clean it out.

    On the feature front, I'd like to see hbox/vbox implemented. Also,
    attachment (pre-constructed DOMs) should be supported out-of-the-box
    as a way to speed up systems like Dojango and ZF which could be made
    template-savvy and could therefore do much of the DOM generating heavy
    lifting for us. I think it's possible to back some of that in to the
    1.3-era APIs, but doing it pervasively and thinking about how the
    template system could better support that pattern is something that
    I'd like to see on the table for 2.0.

    For 2.0, we should make DTL the default template system for widgets
    and remove the direct string replacement syntax from _Templated (e.g.,
    ${somePropertyName}) since we pay a huge runtime cost for that feature
    in widgets that use it and a code cost to support it.

    Lastly, states and data-bound widgets. Many widgets manage states like
    "focused", "disabled", etc. These are common things across most Dijits
    and should be codified in common mixins and CSS styles to support
    them. Data bound widgets should share some minimal mixin API to help
    programmers better understand how to build data-backed widgets and how
    to use them more consistently.

    Obviously, I have something of a wishlist for Core 2.0 as well, but
    I'd like for the Dijit 2.0 stuff to inform those requirements.

    Regards


    On Jan 21, 2009, at 4:54 PM, Bill Keese wrote:
    A while back somebody asked about the road map for Dojo 2.0, and I
    finally gave some thought to dijit.

    There are lots of things people want for the future of dijit,
    documented
    (among other places) in:

    * http://dojotoolkit.org/2007/08/12/widget-wish-list
    * http://www.dojotoolkit.org/2007/11/21/widget-wish-list-response
    * http://www.dojotoolkit.org/2008/09/17/dijit-1-3
    * http://bugs.dojotoolkit.org/report/19

    Most of those tasks, though, could be done either before or after 2.0,
    so they don't need to be tied to the 2.0 release. What I'm looking at
    is the changes that require changes in back-compatibility.
    Specifically my thoughts are:


    General:

    * remove deprecated code (setValue(), etc.)
    * remove deprecated widgets (SplitContainer, LayoutContainer)
    * finish up file split by widget (Button.js and Checkbox.js remain)


    Rename files/classes/directories:

    * Textarea --> ResizableTextArea/AutoSizingTextArea (note case
    change).
    * SimpleTextarea --> TextArea (note case change)
    * _editor --> editor (since plugins aren't really private)
    * _tree --> tree (since dijit._tree.dndSource isn't private)
    * _Widget --> WidgetBase, _Templated --> TemplatedMixin (since they
    are not really private)
    * some (but not all) of these changes could be done now, with
    back-compat stubs


    Widget:

    * rename destroyRecursive() to destroy() and get rid of
    uninitialize()
    * move attributeMap to a mixin?


    Widget Attributes Schema/Parser changes:

    * require widgets to declare their public attributes (a.k.a.
    parameters) explicitly, along w/how to get the parameters from markup
    (from DOM node attributes or from innerHTML via CSS expression)

    * widgets no longer need to query srcNodeRef to get their more
    complex
    parameters

    * parser also has support for Container widgets; parser will call
    addChild() for each child, or maybe pass in a children[] array of
    widgets to the parent widget's constructor

    * parser stops at ContentPane; ContentPane will parse it's own
    content
    when it is displayed. ie, defer parsing of hidden panes in
    TabContainer.


    Widget Events:

    * Users call Widget.subscribe() or Widget.connect() method for
    monitoring events (like onClick) on a widget, rather than calling
    dojo.connect()
    * This removes the need for widgets to implement empty onClick() type
    functions
    * Not sure about documentation, I guess the events each widget
    supports would need to be listed in the widget description

    Themes and CSS:

    * if we want themes to be able to control non-CSS behavior (like
    animations), then we probably have to modify the way users specify the
    theme(s) for a page. Instead of setting <body class="tundra"> maybe
    the
    theme would be a djConfig variable, and to override a theme for a
    particular widget would require setting theme="soria" on that widget.

    * was it a mistake to remove templateCssPath in 1.0? I have to
    think
    about this some more, but anyway, 2.0 is a chance to change how we
    deal
    with CSS.

    TabContainer and friends:

    * remove topics from StackContainer? Can just use simple events.
    * remove StackController altogether? Probably no one is using it.
    * TabContainer implementation can be simplified by removing
    controller
    paradigm (which lets user can create a TabController separately from
    the
    TabContainer). Rather just combine into one widget.


    Build stage?

    * For theme generation (from template files) and possibly other
    things
    I wonder if it makes sense to require a build step. Obviously there
    are
    some disadvantages but I wonder if the pros outweigh the cons.
    Have to
    think about that one.
    * A build could also solve NLS issues such as locale file generation
    (right now a raw checkout only supports a few locales), plus the
    famous
    404 error trying to load language files that don't exist.


    Private / Protected / Public:

    * The _foo naming method doesn't work since it can't distinguish
    private from protected, and also since many of our protected methods
    don't have an underscore, like postCreate(). I guess though this is
    just a question of putting that metadata in comments, so this isn't a
    2.0 issue per se.


    Mixins (suggestion from dylan):

    * Make more things mixins. I was told recently that a11y and i18n
    should be mixins rather than requirements because some apps do not
    need
    them.



    Anyway, those are just some initial thoughts.

    Bill


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Dylan Schiemann at Jan 28, 2009 at 4:28 pm
    I think this is a great possible overall line for what Dojo 2.0 means,
    which even bigger is perhaps "dropping support for all the cruft needed
    for IE 6 and 7."

    Given timing, this would means that 1.x would need to live in parallel
    to 2.x for a *very* long time (3-5 years in my opinion) but that could
    be ok.

    Alternatively, if there are other motivations for 2.0, then this
    suggestion could be the plan for 3.0.

    Regards,
    -Dylan

    Eugene Lazutkin wrote:
    What can I say? In my opinion Alex hit the bull's eye once again --- I
    am +1 on all his points. I started to comment on his proposals, but it
    turned out they are all in the "me too" category, or different arguments
    to the same effect.

    Obviously at some point we need to do a little prototyping to get a feel
    of new APIs and paradigms.

    Thanks,

    Eugene Lazutkin
    Dojo Toolkit, Committer
    SitePen, Developer

    PS: Waiting for the Core 2.0 discussion --- I do too have a wish list
    for it.

    PPS: I want to stress that we should not be afraid to propose
    server-side enhancements and standards. Like Alex said, the CSS
    pre-processor is one but very important example, especially in the light
    of the work I was doing at my work place lately. The pre-instantiation
    of widgets is the other low hanging fruit.


    Alex Russell wrote:
    Hey all:

    My biggest wish is for real getters and setters. This constrains us to
    IE 8+ (other browsers don't suck nearly as much), but if we're gonna
    target the "real future", we could go a very long way toward a faster,
    easier-to-understand system if we could start to melt away more of the
    conceptual overhead of the _Widget class. That's perhaps the most
    controversial thing I'll suggest, and I'm relatively sure that i'll
    get shot down on it. If, OTOH, we do go this route, it would give Core
    the freedom to be similiarly unconstrained and would allow, e.g., the
    Data APIs to become MUCH more natural than they are today.

    Also on my (plumbing) wishlist is a system for parameterizing theme
    CSS. I'll leave it to those handling themes to think more about this,
    but we pay a big price for our current system in several ways:

    1.) descendant selectors slow down application of widget CSS to a
    huge degree
    2.) we always send all the CSS for every browser *to* every browser.
    The build system does not differentiate/trim/generate different
    versions for different browsers despite our CSS workarounds for IE
    being a gigantic proportion of the overall size.
    3.) themes that specialize rely on cascade order for over-rides even
    when "built". This balloons the # and size of the rules, creating a
    lot of rule chaff that again slows down application of styles for
    widgets. Having a better parameterization system might allow us to
    generate better theme-specific .css files
    4.) themes are hard to parameterize because as a result of all of the
    above. The explosion of rules to deal with IE-isms really makes it
    hard for theme authors or tools to easily parameterize what makes one
    theme different from another. I hate suggesting a runtime pre-
    processor for CSS with a build-time equivalent, but it really does
    seem like the best path forward.

    I should re-itereate that our current system rocks. It's pretty easy
    to work with, theme inheritance is understandable, and theme
    application Just Works (TM). All of my suggestions here are not meant
    as criticisms in any way, but rather things that a shiny future might
    hold assuming that browsers aren't going to beat us to things like CSS
    variables and expressions.

    We should also revisit dojo.declare() and its effect on widgets. The
    widget system pays a high cost for inefficiencies in declare(), and
    2.0 seems the right time to peel some of that back and clean it out.

    On the feature front, I'd like to see hbox/vbox implemented. Also,
    attachment (pre-constructed DOMs) should be supported out-of-the-box
    as a way to speed up systems like Dojango and ZF which could be made
    template-savvy and could therefore do much of the DOM generating heavy
    lifting for us. I think it's possible to back some of that in to the
    1.3-era APIs, but doing it pervasively and thinking about how the
    template system could better support that pattern is something that
    I'd like to see on the table for 2.0.

    For 2.0, we should make DTL the default template system for widgets
    and remove the direct string replacement syntax from _Templated (e.g.,
    ${somePropertyName}) since we pay a huge runtime cost for that feature
    in widgets that use it and a code cost to support it.

    Lastly, states and data-bound widgets. Many widgets manage states like
    "focused", "disabled", etc. These are common things across most Dijits
    and should be codified in common mixins and CSS styles to support
    them. Data bound widgets should share some minimal mixin API to help
    programmers better understand how to build data-backed widgets and how
    to use them more consistently.

    Obviously, I have something of a wishlist for Core 2.0 as well, but
    I'd like for the Dijit 2.0 stuff to inform those requirements.

    Regards


    On Jan 21, 2009, at 4:54 PM, Bill Keese wrote:
    A while back somebody asked about the road map for Dojo 2.0, and I
    finally gave some thought to dijit.

    There are lots of things people want for the future of dijit,
    documented
    (among other places) in:

    * http://dojotoolkit.org/2007/08/12/widget-wish-list
    * http://www.dojotoolkit.org/2007/11/21/widget-wish-list-response
    * http://www.dojotoolkit.org/2008/09/17/dijit-1-3
    * http://bugs.dojotoolkit.org/report/19

    Most of those tasks, though, could be done either before or after 2.0,
    so they don't need to be tied to the 2.0 release. What I'm looking at
    is the changes that require changes in back-compatibility.
    Specifically my thoughts are:


    General:

    * remove deprecated code (setValue(), etc.)
    * remove deprecated widgets (SplitContainer, LayoutContainer)
    * finish up file split by widget (Button.js and Checkbox.js remain)


    Rename files/classes/directories:

    * Textarea --> ResizableTextArea/AutoSizingTextArea (note case
    change).
    * SimpleTextarea --> TextArea (note case change)
    * _editor --> editor (since plugins aren't really private)
    * _tree --> tree (since dijit._tree.dndSource isn't private)
    * _Widget --> WidgetBase, _Templated --> TemplatedMixin (since they
    are not really private)
    * some (but not all) of these changes could be done now, with
    back-compat stubs


    Widget:

    * rename destroyRecursive() to destroy() and get rid of
    uninitialize()
    * move attributeMap to a mixin?


    Widget Attributes Schema/Parser changes:

    * require widgets to declare their public attributes (a.k.a.
    parameters) explicitly, along w/how to get the parameters from markup
    (from DOM node attributes or from innerHTML via CSS expression)

    * widgets no longer need to query srcNodeRef to get their more
    complex
    parameters

    * parser also has support for Container widgets; parser will call
    addChild() for each child, or maybe pass in a children[] array of
    widgets to the parent widget's constructor

    * parser stops at ContentPane; ContentPane will parse it's own
    content
    when it is displayed. ie, defer parsing of hidden panes in
    TabContainer.


    Widget Events:

    * Users call Widget.subscribe() or Widget.connect() method for
    monitoring events (like onClick) on a widget, rather than calling
    dojo.connect()
    * This removes the need for widgets to implement empty onClick() type
    functions
    * Not sure about documentation, I guess the events each widget
    supports would need to be listed in the widget description

    Themes and CSS:

    * if we want themes to be able to control non-CSS behavior (like
    animations), then we probably have to modify the way users specify the
    theme(s) for a page. Instead of setting <body class="tundra"> maybe
    the
    theme would be a djConfig variable, and to override a theme for a
    particular widget would require setting theme="soria" on that widget.

    * was it a mistake to remove templateCssPath in 1.0? I have to
    think
    about this some more, but anyway, 2.0 is a chance to change how we
    deal
    with CSS.

    TabContainer and friends:

    * remove topics from StackContainer? Can just use simple events.
    * remove StackController altogether? Probably no one is using it.
    * TabContainer implementation can be simplified by removing
    controller
    paradigm (which lets user can create a TabController separately from
    the
    TabContainer). Rather just combine into one widget.


    Build stage?

    * For theme generation (from template files) and possibly other
    things
    I wonder if it makes sense to require a build step. Obviously there
    are
    some disadvantages but I wonder if the pros outweigh the cons.
    Have to
    think about that one.
    * A build could also solve NLS issues such as locale file generation
    (right now a raw checkout only supports a few locales), plus the
    famous
    404 error trying to load language files that don't exist.


    Private / Protected / Public:

    * The _foo naming method doesn't work since it can't distinguish
    private from protected, and also since many of our protected methods
    don't have an underscore, like postCreate(). I guess though this is
    just a question of putting that metadata in comments, so this isn't a
    2.0 issue per se.


    Mixins (suggestion from dylan):

    * Make more things mixins. I was told recently that a11y and i18n
    should be mixins rather than requirements because some apps do not
    need
    them.



    Anyway, those are just some initial thoughts.

    Bill


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Mike Wilson at Jan 28, 2009 at 5:04 pm

    Eugene Lazutkin wrote:
    The pre-instantiation
    of widgets is the other low hanging fruit.
    I've looked at this a bit, for when we pre-instantiate other
    templates that contain Dojo widgets. I'll try to write some
    observations when I post my summary about templating (which will
    be delayed a fair bit into February due to travelling).

    Dylan Schiemann wrote:
    I think this is a great possible overall line for what Dojo 2.0 means,
    which even bigger is perhaps "dropping support for all the
    cruft needed for IE 6 and 7."

    Given timing, this would means that 1.x would need to live in parallel
    to 2.x for a *very* long time (3-5 years in my opinion) but that could
    be ok.

    Alternatively, if there are other motivations for 2.0, then this
    suggestion could be the plan for 3.0.
    +1

    Even for all the pain I've had with IE6/7 compatibility, I still
    think it's too early to cut them off. Consumer sites will have to
    support them for a long time, which means using Dojo 1.x or
    another library.
    Heck, working on such a site we still have 25% traffic from
    IE6. This is probably from people that will only (indirectly)
    upgrade their browser by buying a new computer, and I agree that
    we will probably not see IE7 disappearing from the stats until 3-5
    years after IE8 is shipping on pre-installed Dells/Gateways/...

    Best regards
    Mike
  • Sam foster at Jan 28, 2009 at 4:49 pm

    Also on my (plumbing) wishlist is a system for parameterizing theme
    CSS. I'll leave it to those handling themes to think more about this,
    +1 to this as a goal, but...
    but we pay a big price for our current system in several ways:

    1.) descendant selectors slow down application of widget CSS to a
    huge degree
    Define huge. I've been looking into this, and while there is a
    measurable cost, its arguable whether flattenning descendent selectors
    down to verbose classesLikeThisThatIncludeAllStateAndVariations really
    trade well against the developer pain they cause
    2.) we always send all the CSS for every browser *to* every browser.
    The build system does not differentiate/trim/generate different
    versions for different browsers despite our CSS workarounds for IE
    being a gigantic proportion of the overall size.
    Again, while I agree with the goal, "gigantic proportion" is a
    stretch, but what proportion there is is directly because of....
    3.) themes that specialize rely on cascade order for over-rides even
    when "built".
    The single thing that would radically improve legibility, conciseness
    and I think performance would be refactoring the CSS to use multiple
    classes. By multiple classes I mean .mainClass.tertiaryClass (note: no
    space). This is the selector to match element class="mainClass
    tertiaryClass". It lets you create truer "classes" and add, augment
    and override their style by adding additional classes to an element.
    There's no need for the css engine to go walking around the dom on
    every change, its localized to a single element. We dont and cant do
    this because IE6 doesnt support it. When we can drop IE6 support we
    can do this. I can image a way to preprocess to generate IE6-specific
    CSS to achieve the same effect, but it would be strange magic from a
    distance and a never-ending headache and source of doubt.

    /Sam
  • Bill Keese at Jan 28, 2009 at 7:03 pm
    Hi Alex, thanks for the response.

    Alex Russell wrote:
    My biggest wish is for real getters and setters. This constrains us to
    IE 8+
    Yeah, I can't really entertain dropping IE6/IE7 support, especially not
    to support an API change (rather than new functionality from an
    end-user's point of view). It seems like supporting what you call
    "real getters and setters", presumably meaning

    widget.foo = "bar"

    rather than

    widget.attr("foo", "bar")

    could be achieved w/a mixin/plugin/whatever, like plugd.
    Also on my (plumbing) wishlist is a system for parameterizing theme
    CSS. I'll leave it to those handling themes to think more about this,
    I'm not sure what "parameterizing" means here other than having separate
    versions per browser?

    The other obvious way to cut down CSS is to only load the CSS for the
    widgets being used. We sort-of support that by telling people to
    customize tundra.css, dropping needless @imports, but that's a PITA and
    it also doesn't address dijit.css.

    In my original post I talked about a different kind of parameters, i.e.
    using CSS variables (or rather something like them) so that themes can
    be customized at a global level, to, for example, set the font of all
    titles, but that's something different I think.

    but we pay a big price for our current system in several ways:

    1.) descendant selectors slow down application of widget CSS to a
    huge degree
    Like Sam said I'd like to see the numbers for this, particularly on IE6
    where our performance is an issue. I'm not worried about the
    performance on other browsers yet since anything slow on safari is
    unusable on IE6.

    3.) themes that specialize rely on cascade order for over-rides even
    when "built". This balloons the # and size of the rules, creating a
    lot of rule chaff that again slows down application of styles for
    widgets. Having a better parameterization system might allow us to
    generate better theme-specific .css files
    Again would need to see numbers on this to prove that it's an issue, but
    if it is an issue:

    There's a lot of cascading going on, for:

    * browser type (.dj_ie6 ...)
    * bidi (.dj_rtl ...)
    * theme name (.tundra ...)
    * nodes underneath Widget.domNode (.dijitInlineEditBox .saveButton)

    Perhaps the first three could be addressed by builds, assuming that we
    modify how theming works so that there's a default theme specified for a
    page, with possibly overrides per widget. (Although again not sure how
    much it's getting us, what's the performance increase / reduction in
    wire size?)

    As for the fourth bullet item, probably "saveButton" should at a minimum
    be called "dijitSaveButton" so it doesn't clash w/possibly user defined
    class names, but changing it to dijitTitlePaneSaveButton means that we
    can't have a general dijitSaveButton class that's used across multiple
    widgets.

    (And note that this is an artificial example because there's only one
    save button in dijit, but things like dijitTitle may make sense in that
    there are titles in multiple widgets (accordion, titlePane, etc.)

    We should also revisit dojo.declare() and its effect on widgets. The
    widget system pays a high cost for inefficiencies in declare(), and
    2.0 seems the right time to peel some of that back and clean it out.
    Hmm, I'm not sure how much cost there is (again would need to see a
    benchmark). Are you talking about page load time?

    We use declare()'s multiple-inheritance support extensively, in the
    sense that we use this.inherited() to call postCreate() (and similar
    functions) defined in every superclass and every mixin class.

    Note that this doesn't work with vanilla javascript as mixins overwrite
    previous definitions.

    For 2.0, we should make DTL the default template system for widgets
    and remove the direct string replacement syntax from _Templated (e.g.,
    ${somePropertyName}) since we pay a huge runtime cost for that feature
    in widgets that use it and a code cost to support it.
    Yeah, I'd like to look into that. I guess it's a back-compat breaking
    change (different template syntax) so 2.0 seems like a good time for it.
    (Although we could also support both engines concurrently).

    As for removing ${somePropertyName} support, that's also a good point in
    that I think we can/should get rid of all such syntax from dijit's own
    templates, after which supporting it is just overhead (albeit how much
    overhead I'm not sure; it's not a lot of code on the wire but perhaps
    there's a tangible increase in widget instantiation time? Would need
    to benchmark.)
  • Nikolai Onken at Feb 3, 2009 at 12:20 pm
    Coming in a bit late to the discussion due to moving house... anyways.

    My currently biggest wishes are still cleaning up the L&F. There are
    still little things we need to clean up and some are unfortunately not
    as easy as they should.
    So in regards to the L&F it would be good to see what we want and then
    see how we can implement. My issues:

    1. Buttons
    -------------
    - Support for rounded buttons

    2. Input elements
    -----------------------
    - All input elements have to have exactly the same height and visual
    appearance

    3. Form validation
    ------------------------
    - Form validation does not look clean and finished (this has been
    discussed already, iirc there is a ticket)

    4. Dialogs
    --------------
    - It would be nice to support rounded dialogs, with dropped shadows
    (in all browsers)

    Some of the issues have been discussed at some point, I have
    investigated some but wasn't able to produce and finished result due
    to time constraints.
    Some require template changes, some require other changes.

    Just a few ideas, I want to work on those, not sure if it makes sense
    to wait for browsers to support rounded corners (since ie8 won't ship
    with them anyways) - unfortunately.

    Nikolai
    On Jan 29, 2009, at 1:03 AM, Bill Keese wrote:

    Hi Alex, thanks for the response.

    Alex Russell wrote:
    My biggest wish is for real getters and setters. This constrains us
    to
    IE 8+
    Yeah, I can't really entertain dropping IE6/IE7 support, especially
    not
    to support an API change (rather than new functionality from an
    end-user's point of view). It seems like supporting what you call
    "real getters and setters", presumably meaning

    widget.foo = "bar"

    rather than

    widget.attr("foo", "bar")

    could be achieved w/a mixin/plugin/whatever, like plugd.
    Also on my (plumbing) wishlist is a system for parameterizing theme
    CSS. I'll leave it to those handling themes to think more about this,
    I'm not sure what "parameterizing" means here other than having
    separate
    versions per browser?

    The other obvious way to cut down CSS is to only load the CSS for the
    widgets being used. We sort-of support that by telling people to
    customize tundra.css, dropping needless @imports, but that's a PITA
    and
    it also doesn't address dijit.css.

    In my original post I talked about a different kind of parameters,
    i.e.
    using CSS variables (or rather something like them) so that themes can
    be customized at a global level, to, for example, set the font of all
    titles, but that's something different I think.

    but we pay a big price for our current system in several ways:

    1.) descendant selectors slow down application of widget CSS to a
    huge degree
    Like Sam said I'd like to see the numbers for this, particularly on
    IE6
    where our performance is an issue. I'm not worried about the
    performance on other browsers yet since anything slow on safari is
    unusable on IE6.

    3.) themes that specialize rely on cascade order for over-rides even
    when "built". This balloons the # and size of the rules, creating a
    lot of rule chaff that again slows down application of styles for
    widgets. Having a better parameterization system might allow us to
    generate better theme-specific .css files
    Again would need to see numbers on this to prove that it's an issue,
    but
    if it is an issue:

    There's a lot of cascading going on, for:

    * browser type (.dj_ie6 ...)
    * bidi (.dj_rtl ...)
    * theme name (.tundra ...)
    * nodes underneath Widget.domNode (.dijitInlineEditBox .saveButton)

    Perhaps the first three could be addressed by builds, assuming that we
    modify how theming works so that there's a default theme specified
    for a
    page, with possibly overrides per widget. (Although again not sure
    how
    much it's getting us, what's the performance increase / reduction in
    wire size?)

    As for the fourth bullet item, probably "saveButton" should at a
    minimum
    be called "dijitSaveButton" so it doesn't clash w/possibly user
    defined
    class names, but changing it to dijitTitlePaneSaveButton means that we
    can't have a general dijitSaveButton class that's used across multiple
    widgets.

    (And note that this is an artificial example because there's only one
    save button in dijit, but things like dijitTitle may make sense in
    that
    there are titles in multiple widgets (accordion, titlePane, etc.)

    We should also revisit dojo.declare() and its effect on widgets. The
    widget system pays a high cost for inefficiencies in declare(), and
    2.0 seems the right time to peel some of that back and clean it out.
    Hmm, I'm not sure how much cost there is (again would need to see a
    benchmark). Are you talking about page load time?

    We use declare()'s multiple-inheritance support extensively, in the
    sense that we use this.inherited() to call postCreate() (and similar
    functions) defined in every superclass and every mixin class.

    Note that this doesn't work with vanilla javascript as mixins
    overwrite
    previous definitions.

    For 2.0, we should make DTL the default template system for widgets
    and remove the direct string replacement syntax from _Templated
    (e.g.,
    ${somePropertyName}) since we pay a huge runtime cost for that
    feature
    in widgets that use it and a code cost to support it.
    Yeah, I'd like to look into that. I guess it's a back-compat
    breaking
    change (different template syntax) so 2.0 seems like a good time for
    it.
    (Although we could also support both engines concurrently).

    As for removing ${somePropertyName} support, that's also a good
    point in
    that I think we can/should get rid of all such syntax from dijit's own
    templates, after which supporting it is just overhead (albeit how much
    overhead I'm not sure; it's not a lot of code on the wire but perhaps
    there's a tangible increase in widget instantiation time? Would need
    to benchmark.)

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bill Keese at Feb 3, 2009 at 11:08 pm
    Oh, one thing I forgot to mention in my original post was the Editor.

    We've been talking about using contentEditable <div> instead of <iframe>
    for a long time. This will become feasible to do across the board once
    we drop FF2 support (either in 1.4 or certainly by 2.0).

    The back-compat issue is with the editor option to specify a special
    style-sheet for just the contents of the editor. These rules are hard
    to apply to a contentEditable <div> since the general style settings for
    the page interfere, and also since we need someway to take a rule like

    p { font: 14pt; }

    and have it only apply to the stuff in the specified editor.

    I think for 2.0 we could just tell users to write custom selectors for
    the content in their editors, like

    #myEditor p { font: 14pt; }

    Of course we could instead do this in javascript, trying to parse the
    CSS file and do conversions, but that seems like a can of worms.


    Maybe there are other back-compat issues too, like about how toolbar
    buttons interact w/the editor, given the issues with saving focus and
    selection?
  • Michael Smith at Feb 4, 2009 at 8:34 pm
    Hi Bill,

    This is the first I've heard of these plans to use a <div> instead of
    an <iframe>. I can't make the weekly #dojo meetings, so that may be
    why. What's the advantage of using a <div>?

    All other JavaScript-based WYSIWYG editors that I've considered using
    in my applications have used an iframe internally to display the
    content. This approach provides a separate window context for CSS,
    JavaScript, and absolute positioning. If the actual content of the
    editor contains inline JavaScript or CSS, it could affect the whole
    browser window. As you mentioned, the editor could parse it out and
    modify for better display, but that's very error prone.

    I also recognize that perhaps right now the editor may not include
    inline JavaScript or CSS as supported content, but I don't think you
    would want to take any design decisions that move in a direction away
    from being able to support them. In the future, it may be a necessary
    requirement. What's the value in using a <div> instead of an <iframe>,
    and does that value outweigh the counterargument?

    Cheers,
    ~Michael


    On Tue, Feb 3, 2009 at 8:08 PM, Bill Keese wrote:

    Oh, one thing I forgot to mention in my original post was the Editor.

    We've been talking about using contentEditable <div> instead of <iframe>
    for a long time. This will become feasible to do across the board once
    we drop FF2 support (either in 1.4 or certainly by 2.0).

    The back-compat issue is with the editor option to specify a special
    style-sheet for just the contents of the editor. These rules are hard
    to apply to a contentEditable <div> since the general style settings for
    the page interfere, and also since we need someway to take a rule like

    p { font: 14pt; }

    and have it only apply to the stuff in the specified editor.

    I think for 2.0 we could just tell users to write custom selectors for
    the content in their editors, like

    #myEditor p { font: 14pt; }

    Of course we could instead do this in javascript, trying to parse the
    CSS file and do conversions, but that seems like a can of worms.


    Maybe there are other back-compat issues too, like about how toolbar
    buttons interact w/the editor, given the issues with saving focus and
    selection?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bill Keese at Feb 4, 2009 at 8:46 pm

    Michael Smith wrote:
    Hi Bill,

    This is the first I've heard of these plans to use a <div> instead of
    an <iframe>. I can't make the weekly #dojo meetings, so that may be
    why. What's the advantage of using a <div>?
    I'm not an expert on it.

    Dylan tells me that "iframe works fine in the tests but falls over in
    real life", or something to that effect, so probably he or Alex should
    answer.

    I know there are a lot of timing issues waiting for an iframe to
    initialize, and also https related issues, and I suppose using an iframe
    precludes things like drag-and-drop into the editor (from the main
    document).

    OTOH maybe people just want to use the contentEditable <div> because
    it's newer and cooler.

    Probably in the past, and until the near future, it didn't/doesn't make
    sense to use a contentEditable <div> in any DHTML editor since FF2
    didn't support it, but as soon as we drop FF2 support that restriction
    goes away.

Related Discussions

People

Translate

site design / logo © 2021 Grokbase