I recently spent some time creating Dojo's entry (
https://github.com/jthomas/todomvc) for the TodoMVC project (
http://addyosmani.github.com/todomvc/) with help from Ed Chatelain and Ben
Hockey. Never having used DojoX MVC before, I kept notes on issues
encountered creating the application to provide some feedback on using the
module to build a simply MVC application.
*
*
*Overall, it worked really well and I definitely think we need to publicise
this aspect of the toolkit much more.* *Newer toolkits (Backbone, Spine)
really promote their MVC support and I'm not sure many of our users know we
can do the same. *

** Extend StatefulModel API for arrays*

Dealing with arrays was one of my main "pain points". It would be nice to
have convenience methods like "push", "pop", for modifying arrays rather
than having to use "add", "remove" with explicit array indices. Adding a
new todo item meant having to explicitly include new list position as an
argument which seems a bit unintuitive to me (
https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/app.js#L89
).

Removing a series of elements from an array (clearing all completed todos)
was painful as you can only remove the elements by explicit index and we
have to deal with the remaining list indices left-shifting each time we
remove an element (
https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/app.js#L61-78).
Also found "bindInputs" wouldn't trigger on modifying array elements, had
to fall back to "watch"
https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/model/TodoModel.js#L60

Would be nice to mirror Backbone's "Collection" model class by having our
own "StatefulArray" class with the usual functions for operating on arrays?

** Support composite values as part of model declaration*

We had two attributes in the model, "completed" and "remaining", that were
composite attributes (calculated from other values). Would be nice if the
StatefulModel supported declare these in meta-data for the StatefulModel
rather than having to manually execute the mvc.bind method during
instantiation.
https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/model/TodoModel.js#L44-46
*
*
** Allow binding to inner attributes updates in child models from the
parent. *
*
*
Whenever the user modifies the checkbox, that todo item's model boolean
value is updated and we can to re-calculate the "completed" and "remaining"
model values. I couldn't find a way to bind to any changes to child model
inner attributes from the parent "todo" model. The code has to manually
bind to the "isDone" attribute on every child model, rather than listening
for changes to the parent model array. This is more of a stretch goal but
it would have been useful to have changes "bubble" up to the parent models.
https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/model/TodoModel.js#L68-70

** Conditionals in view templates*
*
*
If the user has completed some tasks and/or has some remaining, the view
should show the "stats" element at the bottom of the page. Most of the
other library examples used conditional logic in their templates to achieve
this but I had to bind to a model change, manually toggling CSS classes
representing the state.
https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/app.js#L96-99

I was under the assumption that DojoX DTL was pretty much dormant, have we
got any plans to include this functionality in our dijit templating code in
2.0 or would fall under an MVC improvement?

*Reviewing the 1.8 MVC specification (
https://docs.google.com/document/d/1ejZlUwySI0q3n3scInw30drHa7no7Zm-WSZqtYx5scE/edit),
there are already plans to fix some issues I encountered...*

** Binding to any widget property, not just "value".*

Hit this issue trying to bind the dijit.form.CheckBox widgets to the
StatefulModel, due to the "value" and "checked" attributes.

** Docs, Demo App, Integration with DojoX App*

Found documentation sufficient for DojoX MVC but I did read the MVC code
before starting so I'm probably not that representative of a new user.

Hopefully this application will provide a good reference for getting
started with DojoX MVC, but it'd be nice to have a less trivial example and
also show integration with DojoX App and other parts of the toolkit.

Regards,
James Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120121/6bb2c9a8/attachment.htm

Search Discussions

  • Sasha Firsov at Jan 21, 2012 at 1:15 pm
    Hi James,
    /Newer toolkits (Backbone, Spine) really promote their MVC support and
    I'm not sure many of our users know we can do the same.
    /
    I would not get too excited on Backbone or Spine. Those are not samples
    of good design and clear mind. But agree, they are good in brainwash
    playing with MVC words. I sincerely hope that we would not do same.

    DojoX MVC is just separate package which does not reflect the MVC power
    of other components. Instead I would point to dojo store(M),
    TreeStoreModel(C), dijit.Tree(V) as a good MVC sample. Unfortunately
    the naming convention in dojo does not match popular architectural
    terms. Another issue that not all components are fitting to same MVC
    delivery chain.
    I had in mind to create reusable controller out of TreeStoreModel and
    use it for dojo.store to [tab, accordion, form,...] chaining. With a
    goal to keep data in hierarchical tree structure keeping in sync.
    DojoX MVC is not best candidate just because less coherent with existing
    dijits :(

    Sasha

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120121/87e42901/attachment.htm
  • Kenneth G. Franqueiro at Jan 21, 2012 at 1:56 pm
    While I haven't had a chance to look at the TodoMVC example yet, from
    what I saw when I was researching the dojox/mvc package a bit, I
    somewhat agree with Sasha's sentiment regarding which aspects of Dojo
    really deserve the spotlight for promoting separation of concerns
    (particularly dojo/store).

    The vibe I got from the dojox/mvc package is that it's not so much about
    separation of concerns, and a lot more about binding them together. It
    felt rather heavy (with all the Statefuls and watches it hooks up), and
    *far* too reliant on declarative markup. While I realize that
    templating is usually a part of these frameworks, I sort of feel that
    the most scalable applications built using Dojo lean on declarative
    markup as little as possible (other than for widget templates). The
    only piece of dojox/mvc that looked particularly conducive to
    programmatic use to me was the Generate module, but that seemed somewhat
    limited in usefulness currently, and it still creates declarative markup
    to be run through the parser - meaning it's actually even heavier!

    Admittedly though, I'm rather uninitiated to DojoX MVC (and relatively,
    to MVC frameworks in general), so maybe my concerns don't make a whole
    lot of sense. I do realize that the package lends itself to certain
    types of cases and could significantly expedite the process for said
    cases. I guess my premature-optimization OCD just quickly gets the
    better of me. I suppose maybe the project I was potentially looking at
    it for didn't seem like the type to significantly reap the benefits from
    the full feature set DojoX MVC provides, to justify the weight.

    I'm sorry if this sounds like I'm raining on the parade. It'd be great
    if we can improve DojoX MVC's image by addressing some of these concerns
    though.

    Thanks,
    --Ken
    On 1/21/2012 1:15 PM, Sasha Firsov wrote:
    Hi James,
    /Newer toolkits (Backbone, Spine) really promote their MVC support and
    I'm not sure many of our users know we can do the same.
    /
    I would not get too excited on Backbone or Spine. Those are not samples
    of good design and clear mind. But agree, they are good in brainwash
    playing with MVC words. I sincerely hope that we would not do same.

    DojoX MVC is just separate package which does not reflect the MVC power
    of other components. Instead I would point to dojo store(M),
    TreeStoreModel(C), dijit.Tree(V) as a good MVC sample. Unfortunately
    the naming convention in dojo does not match popular architectural
    terms. Another issue that not all components are fitting to same MVC
    delivery chain.
    I had in mind to create reusable controller out of TreeStoreModel and
    use it for dojo.store to [tab, accordion, form,...] chaining. With a
    goal to keep data in hierarchical tree structure keeping in sync.
    DojoX MVC is not best candidate just because less coherent with existing
    dijits :(

    Sasha



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Ben hockey at Jan 21, 2012 at 3:22 pm
    i've been an enthusiastic early adopter of dojox/mvc and have
    attempted to make use of it extensively in a "real" project. if you
    look through the mvc issues in trac you'll see that i've either
    reported, patched or heavily commented on many of the tickets. i feel
    like i gave it a fair chance during the last ~6 months.

    i'm sorry to say that as of this month i gave up on using it in my
    "real" project. at first i was so excited to be able to bind values
    from a model to a widget but i soon ran into limitations. i'm so glad
    that james made notes - i think you really covered the main pain
    points james. i recently commented on a design doc relating to dojox/
    mvc and i had trouble recalling details of my struggles but you've
    covered it well. also ken, raining on a parade or not, it seems your
    assessment is reasonably accurate too - particularly the comments
    relating to declarative markup.

    i won't repeat the points again but i would need a majority of the
    points raised by james and ken to be addressed before i could consider
    using dojox/mvc again. i don't want to give up on dojox/mvc
    completely and so i'll still be watching and participating where
    possible to try and see improvements made.

    in my frustration, i've been looking to alternatives that could meet
    my need. knockout [1] seemed somewhat appealing but seems like it
    would need a little shaping to make it play nicely with dijit. so far
    i haven't quite found what i need.

    however, i went back through our mailing list archives to see early
    discussions surrounding mvc - i remembered that there had been some
    input about ways to improve dojox/mvc even from the start. i came
    across a post from alex [2] mentioning some work on Property Models.
    reading some of the papers surrounding this work [3] has got me really
    excited. i dug around for a little while longer and found that the
    work has made its way into the world of javascript as a library called
    hotdrink [4]. i was even more excited to see that they have a
    tutorial [5] and a demo [6] that shows how to bind a dijit.form.Slider
    to a Property Model. woo hoo!

    i've been looking over the code in hotdrink and i'm going to look
    further into seeing if it can be useful to me somehow. the part
    that's most appealing to me is that the binding from the model to the
    view and the building of the view is general enough that it doesn't
    matter if the views are dijit or plain DOM elements or anything else.
    i'm not even completely sold on the declarative sheets - adam (a
    syntax for declaring property models) and eve (a syntax for declaring
    view layouts) but those are interesting too.

    for anyone interested in this area, i'd highly recommend taking the
    time to become familiar with property models even if its just an
    academic exercise for you.

    thanks,

    ben...

    [1] http://knockoutjs.com/
    [2] http://thread.gmane.org/gmane.comp.web.dojo.devel/12868
    [3] http://code.google.com/p/hotdrink/downloads/list
    [4] http://code.google.com/p/hotdrink/
    [5] http://code.google.com/p/hotdrink/wiki/NewWidget
    [6] https://parasol.tamu.edu/groups/pttlgroup/hotdrink/test/slider.php

    On Jan 21, 2012, at 1:56 PM, Kenneth G. Franqueiro wrote:

    While I haven't had a chance to look at the TodoMVC example yet, from
    what I saw when I was researching the dojox/mvc package a bit, I
    somewhat agree with Sasha's sentiment regarding which aspects of Dojo
    really deserve the spotlight for promoting separation of concerns
    (particularly dojo/store).

    The vibe I got from the dojox/mvc package is that it's not so much
    about
    separation of concerns, and a lot more about binding them together.
    It
    felt rather heavy (with all the Statefuls and watches it hooks up),
    and
    *far* too reliant on declarative markup. While I realize that
    templating is usually a part of these frameworks, I sort of feel that
    the most scalable applications built using Dojo lean on declarative
    markup as little as possible (other than for widget templates). The
    only piece of dojox/mvc that looked particularly conducive to
    programmatic use to me was the Generate module, but that seemed
    somewhat
    limited in usefulness currently, and it still creates declarative
    markup
    to be run through the parser - meaning it's actually even heavier!

    Admittedly though, I'm rather uninitiated to DojoX MVC (and
    relatively,
    to MVC frameworks in general), so maybe my concerns don't make a whole
    lot of sense. I do realize that the package lends itself to certain
    types of cases and could significantly expedite the process for said
    cases. I guess my premature-optimization OCD just quickly gets the
    better of me. I suppose maybe the project I was potentially looking
    at
    it for didn't seem like the type to significantly reap the benefits
    from
    the full feature set DojoX MVC provides, to justify the weight.

    I'm sorry if this sounds like I'm raining on the parade. It'd be
    great
    if we can improve DojoX MVC's image by addressing some of these
    concerns
    though.

    Thanks,
    --Ken
    On 1/21/2012 1:15 PM, Sasha Firsov wrote:
    Hi James,
    /Newer toolkits (Backbone, Spine) really promote their MVC support
    and
    I'm not sure many of our users know we can do the same.
    /
    I would not get too excited on Backbone or Spine. Those are not
    samples
    of good design and clear mind. But agree, they are good in brainwash
    playing with MVC words. I sincerely hope that we would not do same.

    DojoX MVC is just separate package which does not reflect the MVC
    power
    of other components. Instead I would point to dojo store(M),
    TreeStoreModel(C), dijit.Tree(V) as a good MVC sample. Unfortunately
    the naming convention in dojo does not match popular architectural
    terms. Another issue that not all components are fitting to same MVC
    delivery chain.
    I had in mind to create reusable controller out of TreeStoreModel and
    use it for dojo.store to [tab, accordion, form,...] chaining. With a
    goal to keep data in hierarchical tree structure keeping in sync.
    DojoX MVC is not best candidate just because less coherent with
    existing
    dijits :(

    Sasha



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120121/cad0622f/attachment.htm
  • Ed Chatelain at Jan 21, 2012 at 4:04 pm
    Thanks for all of the feedback on dojox.mvc, especially to Ben who has been
    a huge help with it up to now. We are currently working on improvements
    for 1.8, and will definitely try to as much as we can from the issues
    mentioned in the thread. Keep the feedback coming and we will keep trying
    to make improvements.

    Ed Chatelain

    2012/1/21 ben hockey <neonstalwart at gmail.com>
    i've been an enthusiastic early adopter of dojox/mvc and have attempted to
    make use of it extensively in a "real" project. if you look through the
    mvc issues in trac you'll see that i've either reported, patched or heavily
    commented on many of the tickets. i feel like i gave it a fair chance
    during the last ~6 months.

    i'm sorry to say that as of this month i gave up on using it in my "real"
    project. at first i was so excited to be able to bind values from a model
    to a widget but i soon ran into limitations. i'm so glad that james made
    notes - i think you really covered the main pain points james. i recently
    commented on a design doc relating to dojox/mvc and i had trouble recalling
    details of my struggles but you've covered it well. also ken, raining on a
    parade or not, it seems your assessment is reasonably accurate too -
    particularly the comments relating to declarative markup.

    i won't repeat the points again but i would need a majority of the points
    raised by james and ken to be addressed before i could consider using
    dojox/mvc again. i don't want to give up on dojox/mvc completely and so
    i'll still be watching and participating where possible to try and see
    improvements made.

    in my frustration, i've been looking to alternatives that could meet my
    need. knockout [1] seemed somewhat appealing but seems like it would need
    a little shaping to make it play nicely with dijit. so far i haven't quite
    found what i need.

    however, i went back through our mailing list archives to see early
    discussions surrounding mvc - i remembered that there had been some input
    about ways to improve dojox/mvc even from the start. i came across a post
    from alex [2] mentioning some work on Property Models. reading some of the
    papers surrounding this work [3] has got me really excited. i dug around
    for a little while longer and found that the work has made its way into the
    world of javascript as a library called hotdrink [4]. i was even more
    excited to see that they have a tutorial [5] and a demo [6] that shows how
    to bind a dijit.form.Slider to a Property Model. woo hoo!

    i've been looking over the code in hotdrink and i'm going to look further
    into seeing if it can be useful to me somehow. the part that's most
    appealing to me is that the binding from the model to the view and the
    building of the view is general enough that it doesn't matter if the views
    are dijit or plain DOM elements or anything else. i'm not even completely
    sold on the declarative sheets - adam (a syntax for declaring property
    models) and eve (a syntax for declaring view layouts) but those are
    interesting too.

    for anyone interested in this area, i'd highly recommend taking the time
    to become familiar with property models even if its just an academic
    exercise for you.

    thanks,

    ben...

    [1] http://knockoutjs.com/
    [2] http://thread.gmane.org/gmane.comp.web.dojo.devel/12868
    [3] http://code.google.com/p/hotdrink/downloads/list
    [4] http://code.google.com/p/hotdrink/
    [5] http://code.google.com/p/hotdrink/wiki/NewWidget
    [6] https://parasol.tamu.edu/groups/pttlgroup/hotdrink/test/slider.php


    On Jan 21, 2012, at 1:56 PM, Kenneth G. Franqueiro wrote:

    While I haven't had a chance to look at the TodoMVC example yet, from
    what I saw when I was researching the dojox/mvc package a bit, I
    somewhat agree with Sasha's sentiment regarding which aspects of Dojo
    really deserve the spotlight for promoting separation of concerns
    (particularly dojo/store).

    The vibe I got from the dojox/mvc package is that it's not so much about
    separation of concerns, and a lot more about binding them together. It
    felt rather heavy (with all the Statefuls and watches it hooks up), and
    *far* too reliant on declarative markup. While I realize that
    templating is usually a part of these frameworks, I sort of feel that
    the most scalable applications built using Dojo lean on declarative
    markup as little as possible (other than for widget templates). The
    only piece of dojox/mvc that looked particularly conducive to
    programmatic use to me was the Generate module, but that seemed somewhat
    limited in usefulness currently, and it still creates declarative markup
    to be run through the parser - meaning it's actually even heavier!

    Admittedly though, I'm rather uninitiated to DojoX MVC (and relatively,
    to MVC frameworks in general), so maybe my concerns don't make a whole
    lot of sense. I do realize that the package lends itself to certain
    types of cases and could significantly expedite the process for said
    cases. I guess my premature-optimization OCD just quickly gets the
    better of me. I suppose maybe the project I was potentially looking at
    it for didn't seem like the type to significantly reap the benefits from
    the full feature set DojoX MVC provides, to justify the weight.

    I'm sorry if this sounds like I'm raining on the parade. It'd be great
    if we can improve DojoX MVC's image by addressing some of these concerns
    though.

    Thanks,
    --Ken

    On 1/21/2012 1:15 PM, Sasha Firsov wrote:

    Hi James,


    /Newer toolkits (Backbone, Spine) really promote their MVC support and

    I'm not sure many of our users know we can do the same.

    /

    I would not get too excited on Backbone or Spine. Those are not samples

    of good design and clear mind. But agree, they are good in brainwash

    playing with MVC words. I sincerely hope that we would not do same.


    DojoX MVC is just separate package which does not reflect the MVC power

    of other components. Instead I would point to dojo store(M),

    TreeStoreModel(C), dijit.Tree(V) as a good MVC sample. Unfortunately

    the naming convention in dojo does not match popular architectural

    terms. Another issue that not all components are fitting to same MVC

    delivery chain.

    I had in mind to create reusable controller out of TreeStoreModel and

    use it for dojo.store to [tab, accordion, form,...] chaining. With a

    goal to keep data in hierarchical tree structure keeping in sync.

    DojoX MVC is not best candidate just because less coherent with existing

    dijits :(


    Sasha




    _______________________________________________

    dojo-contributors mailing list

    dojo-contributors at mail.dojotoolkit.org

    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

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



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

    --
    Ed Chatelain
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120121/de5d119b/attachment-0001.htm
  • Ed Chatelain at Jan 26, 2012 at 2:44 pm
    Ben,
    I am open to the possibility of creating a lightweight model in the
    dojox.mvc package in addition to the current StatefulModel, if we can come
    up with a name and an API which would not completely confuse everyone. I
    don't want to get rid of the current StatefulModel but I do understand that
    it is a bit heavy. Over time we could see which model works best.

    Regards,
    Ed

    2012/1/21 ben hockey <neonstalwart at gmail.com>
    i've been an enthusiastic early adopter of dojox/mvc and have attempted to
    make use of it extensively in a "real" project. if you look through the
    mvc issues in trac you'll see that i've either reported, patched or heavily
    commented on many of the tickets. i feel like i gave it a fair chance
    during the last ~6 months.

    i'm sorry to say that as of this month i gave up on using it in my "real"
    project. at first i was so excited to be able to bind values from a model
    to a widget but i soon ran into limitations. i'm so glad that james made
    notes - i think you really covered the main pain points james. i recently
    commented on a design doc relating to dojox/mvc and i had trouble recalling
    details of my struggles but you've covered it well. also ken, raining on a
    parade or not, it seems your assessment is reasonably accurate too -
    particularly the comments relating to declarative markup.

    i won't repeat the points again but i would need a majority of the points
    raised by james and ken to be addressed before i could consider using
    dojox/mvc again. i don't want to give up on dojox/mvc completely and so
    i'll still be watching and participating where possible to try and see
    improvements made.

    in my frustration, i've been looking to alternatives that could meet my
    need. knockout [1] seemed somewhat appealing but seems like it would need
    a little shaping to make it play nicely with dijit. so far i haven't quite
    found what i need.

    however, i went back through our mailing list archives to see early
    discussions surrounding mvc - i remembered that there had been some input
    about ways to improve dojox/mvc even from the start. i came across a post
    from alex [2] mentioning some work on Property Models. reading some of the
    papers surrounding this work [3] has got me really excited. i dug around
    for a little while longer and found that the work has made its way into the
    world of javascript as a library called hotdrink [4]. i was even more
    excited to see that they have a tutorial [5] and a demo [6] that shows how
    to bind a dijit.form.Slider to a Property Model. woo hoo!

    i've been looking over the code in hotdrink and i'm going to look further
    into seeing if it can be useful to me somehow. the part that's most
    appealing to me is that the binding from the model to the view and the
    building of the view is general enough that it doesn't matter if the views
    are dijit or plain DOM elements or anything else. i'm not even completely
    sold on the declarative sheets - adam (a syntax for declaring property
    models) and eve (a syntax for declaring view layouts) but those are
    interesting too.

    for anyone interested in this area, i'd highly recommend taking the time
    to become familiar with property models even if its just an academic
    exercise for you.

    thanks,

    ben...

    [1] http://knockoutjs.com/
    [2] http://thread.gmane.org/gmane.comp.web.dojo.devel/12868
    [3] http://code.google.com/p/hotdrink/downloads/list
    [4] http://code.google.com/p/hotdrink/
    [5] http://code.google.com/p/hotdrink/wiki/NewWidget
    [6] https://parasol.tamu.edu/groups/pttlgroup/hotdrink/test/slider.php


    On Jan 21, 2012, at 1:56 PM, Kenneth G. Franqueiro wrote:

    While I haven't had a chance to look at the TodoMVC example yet, from
    what I saw when I was researching the dojox/mvc package a bit, I
    somewhat agree with Sasha's sentiment regarding which aspects of Dojo
    really deserve the spotlight for promoting separation of concerns
    (particularly dojo/store).

    The vibe I got from the dojox/mvc package is that it's not so much about
    separation of concerns, and a lot more about binding them together. It
    felt rather heavy (with all the Statefuls and watches it hooks up), and
    *far* too reliant on declarative markup. While I realize that
    templating is usually a part of these frameworks, I sort of feel that
    the most scalable applications built using Dojo lean on declarative
    markup as little as possible (other than for widget templates). The
    only piece of dojox/mvc that looked particularly conducive to
    programmatic use to me was the Generate module, but that seemed somewhat
    limited in usefulness currently, and it still creates declarative markup
    to be run through the parser - meaning it's actually even heavier!

    Admittedly though, I'm rather uninitiated to DojoX MVC (and relatively,
    to MVC frameworks in general), so maybe my concerns don't make a whole
    lot of sense. I do realize that the package lends itself to certain
    types of cases and could significantly expedite the process for said
    cases. I guess my premature-optimization OCD just quickly gets the
    better of me. I suppose maybe the project I was potentially looking at
    it for didn't seem like the type to significantly reap the benefits from
    the full feature set DojoX MVC provides, to justify the weight.

    I'm sorry if this sounds like I'm raining on the parade. It'd be great
    if we can improve DojoX MVC's image by addressing some of these concerns
    though.

    Thanks,
    --Ken

    On 1/21/2012 1:15 PM, Sasha Firsov wrote:

    Hi James,


    /Newer toolkits (Backbone, Spine) really promote their MVC support and

    I'm not sure many of our users know we can do the same.

    /

    I would not get too excited on Backbone or Spine. Those are not samples

    of good design and clear mind. But agree, they are good in brainwash

    playing with MVC words. I sincerely hope that we would not do same.


    DojoX MVC is just separate package which does not reflect the MVC power

    of other components. Instead I would point to dojo store(M),

    TreeStoreModel(C), dijit.Tree(V) as a good MVC sample. Unfortunately

    the naming convention in dojo does not match popular architectural

    terms. Another issue that not all components are fitting to same MVC

    delivery chain.

    I had in mind to create reusable controller out of TreeStoreModel and

    use it for dojo.store to [tab, accordion, form,...] chaining. With a

    goal to keep data in hierarchical tree structure keeping in sync.

    DojoX MVC is not best candidate just because less coherent with existing

    dijits :(


    Sasha




    _______________________________________________

    dojo-contributors mailing list

    dojo-contributors at mail.dojotoolkit.org

    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

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



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

    --
    Ed Chatelain
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120126/66e0f08c/attachment-0001.htm
  • James Thomas at Jan 31, 2012 at 3:27 pm
    +1 on this, I'd happily play with something lighter and see how it works.

    2012/1/26 Ed Chatelain <ed.chatelain at gmail.com>
    Ben,
    I am open to the possibility of creating a lightweight model in
    the dojox.mvc package in addition to the current StatefulModel, if we can
    come up with a name and an API which would not completely confuse
    everyone. I don't want to get rid of the current StatefulModel but I do
    understand that it is a bit heavy. Over time we could see which model
    works best.

    Regards,
    Ed


    2012/1/21 ben hockey <neonstalwart at gmail.com>
    i've been an enthusiastic early adopter of dojox/mvc and have attempted
    to make use of it extensively in a "real" project. if you look through the
    mvc issues in trac you'll see that i've either reported, patched or heavily
    commented on many of the tickets. i feel like i gave it a fair chance
    during the last ~6 months.

    i'm sorry to say that as of this month i gave up on using it in my "real"
    project. at first i was so excited to be able to bind values from a model
    to a widget but i soon ran into limitations. i'm so glad that james made
    notes - i think you really covered the main pain points james. i recently
    commented on a design doc relating to dojox/mvc and i had trouble recalling
    details of my struggles but you've covered it well. also ken, raining on a
    parade or not, it seems your assessment is reasonably accurate too -
    particularly the comments relating to declarative markup.

    i won't repeat the points again but i would need a majority of the points
    raised by james and ken to be addressed before i could consider using
    dojox/mvc again. i don't want to give up on dojox/mvc completely and so
    i'll still be watching and participating where possible to try and see
    improvements made.

    in my frustration, i've been looking to alternatives that could meet my
    need. knockout [1] seemed somewhat appealing but seems like it would need
    a little shaping to make it play nicely with dijit. so far i haven't quite
    found what i need.

    however, i went back through our mailing list archives to see early
    discussions surrounding mvc - i remembered that there had been some input
    about ways to improve dojox/mvc even from the start. i came across a post
    from alex [2] mentioning some work on Property Models. reading some of the
    papers surrounding this work [3] has got me really excited. i dug around
    for a little while longer and found that the work has made its way into the
    world of javascript as a library called hotdrink [4]. i was even more
    excited to see that they have a tutorial [5] and a demo [6] that shows how
    to bind a dijit.form.Slider to a Property Model. woo hoo!

    i've been looking over the code in hotdrink and i'm going to look further
    into seeing if it can be useful to me somehow. the part that's most
    appealing to me is that the binding from the model to the view and the
    building of the view is general enough that it doesn't matter if the views
    are dijit or plain DOM elements or anything else. i'm not even completely
    sold on the declarative sheets - adam (a syntax for declaring property
    models) and eve (a syntax for declaring view layouts) but those are
    interesting too.

    for anyone interested in this area, i'd highly recommend taking the time
    to become familiar with property models even if its just an academic
    exercise for you.

    thanks,

    ben...

    [1] http://knockoutjs.com/
    [2] http://thread.gmane.org/gmane.comp.web.dojo.devel/12868
    [3] http://code.google.com/p/hotdrink/downloads/list
    [4] http://code.google.com/p/hotdrink/
    [5] http://code.google.com/p/hotdrink/wiki/NewWidget
    [6] https://parasol.tamu.edu/groups/pttlgroup/hotdrink/test/slider.php


    On Jan 21, 2012, at 1:56 PM, Kenneth G. Franqueiro wrote:

    While I haven't had a chance to look at the TodoMVC example yet, from
    what I saw when I was researching the dojox/mvc package a bit, I
    somewhat agree with Sasha's sentiment regarding which aspects of Dojo
    really deserve the spotlight for promoting separation of concerns
    (particularly dojo/store).

    The vibe I got from the dojox/mvc package is that it's not so much about
    separation of concerns, and a lot more about binding them together. It
    felt rather heavy (with all the Statefuls and watches it hooks up), and
    *far* too reliant on declarative markup. While I realize that
    templating is usually a part of these frameworks, I sort of feel that
    the most scalable applications built using Dojo lean on declarative
    markup as little as possible (other than for widget templates). The
    only piece of dojox/mvc that looked particularly conducive to
    programmatic use to me was the Generate module, but that seemed somewhat
    limited in usefulness currently, and it still creates declarative markup
    to be run through the parser - meaning it's actually even heavier!

    Admittedly though, I'm rather uninitiated to DojoX MVC (and relatively,
    to MVC frameworks in general), so maybe my concerns don't make a whole
    lot of sense. I do realize that the package lends itself to certain
    types of cases and could significantly expedite the process for said
    cases. I guess my premature-optimization OCD just quickly gets the
    better of me. I suppose maybe the project I was potentially looking at
    it for didn't seem like the type to significantly reap the benefits from
    the full feature set DojoX MVC provides, to justify the weight.

    I'm sorry if this sounds like I'm raining on the parade. It'd be great
    if we can improve DojoX MVC's image by addressing some of these concerns
    though.

    Thanks,
    --Ken

    On 1/21/2012 1:15 PM, Sasha Firsov wrote:

    Hi James,


    /Newer toolkits (Backbone, Spine) really promote their MVC support and

    I'm not sure many of our users know we can do the same.

    /

    I would not get too excited on Backbone or Spine. Those are not samples

    of good design and clear mind. But agree, they are good in brainwash

    playing with MVC words. I sincerely hope that we would not do same.


    DojoX MVC is just separate package which does not reflect the MVC power

    of other components. Instead I would point to dojo store(M),

    TreeStoreModel(C), dijit.Tree(V) as a good MVC sample. Unfortunately

    the naming convention in dojo does not match popular architectural

    terms. Another issue that not all components are fitting to same MVC

    delivery chain.

    I had in mind to create reusable controller out of TreeStoreModel and

    use it for dojo.store to [tab, accordion, form,...] chaining. With a

    goal to keep data in hierarchical tree structure keeping in sync.

    DojoX MVC is not best candidate just because less coherent with existing

    dijits :(


    Sasha




    _______________________________________________

    dojo-contributors mailing list

    dojo-contributors at mail.dojotoolkit.org

    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

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



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

    --
    Ed Chatelain

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

    --
    Regards,
    James Thomas
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120131/92cd24b4/attachment.htm
  • Bill Keese at Feb 1, 2012 at 6:55 am
    I wish I had time to keep up with the whole MVC discussion.

    As far as "something lighter", a long time ago Stephen Chung had made an
    alternate suggestion of an API to bind any obj1.attr1 to another
    obj2.attr2. It was at http://www.mingleplace.com/test/bindingtest.html but
    unfortunately that page disappeared.

    2012/2/1 James Thomas <jthomas.uk at gmail.com>
    +1 on this, I'd happily play with something lighter and see how it works.


    2012/1/26 Ed Chatelain <ed.chatelain at gmail.com>
    Ben,
    I am open to the possibility of creating a lightweight model in
    the dojox.mvc package in addition to the current StatefulModel, if we can
    come up with a name and an API which would not completely confuse
    everyone. I don't want to get rid of the current StatefulModel but I do
    understand that it is a bit heavy. Over time we could see which model
    works best.

    Regards,
    Ed


    2012/1/21 ben hockey <neonstalwart at gmail.com>
    i've been an enthusiastic early adopter of dojox/mvc and have attempted
    to make use of it extensively in a "real" project. if you look through the
    mvc issues in trac you'll see that i've either reported, patched or heavily
    commented on many of the tickets. i feel like i gave it a fair chance
    during the last ~6 months.

    i'm sorry to say that as of this month i gave up on using it in my
    "real" project. at first i was so excited to be able to bind values from a
    model to a widget but i soon ran into limitations. i'm so glad that james
    made notes - i think you really covered the main pain points james. i
    recently commented on a design doc relating to dojox/mvc and i had trouble
    recalling details of my struggles but you've covered it well. also ken,
    raining on a parade or not, it seems your assessment is reasonably accurate
    too - particularly the comments relating to declarative markup.

    i won't repeat the points again but i would need a majority of the
    points raised by james and ken to be addressed before i could consider
    using dojox/mvc again. i don't want to give up on dojox/mvc completely and
    so i'll still be watching and participating where possible to try and see
    improvements made.

    in my frustration, i've been looking to alternatives that could meet my
    need. knockout [1] seemed somewhat appealing but seems like it would need
    a little shaping to make it play nicely with dijit. so far i haven't quite
    found what i need.

    however, i went back through our mailing list archives to see early
    discussions surrounding mvc - i remembered that there had been some input
    about ways to improve dojox/mvc even from the start. i came across a post
    from alex [2] mentioning some work on Property Models. reading some of the
    papers surrounding this work [3] has got me really excited. i dug around
    for a little while longer and found that the work has made its way into the
    world of javascript as a library called hotdrink [4]. i was even more
    excited to see that they have a tutorial [5] and a demo [6] that shows how
    to bind a dijit.form.Slider to a Property Model. woo hoo!

    i've been looking over the code in hotdrink and i'm going to look
    further into seeing if it can be useful to me somehow. the part that's
    most appealing to me is that the binding from the model to the view and the
    building of the view is general enough that it doesn't matter if the views
    are dijit or plain DOM elements or anything else. i'm not even completely
    sold on the declarative sheets - adam (a syntax for declaring property
    models) and eve (a syntax for declaring view layouts) but those are
    interesting too.

    for anyone interested in this area, i'd highly recommend taking the time
    to become familiar with property models even if its just an academic
    exercise for you.

    thanks,

    ben...

    [1] http://knockoutjs.com/
    [2] http://thread.gmane.org/gmane.comp.web.dojo.devel/12868
    [3] http://code.google.com/p/hotdrink/downloads/list
    [4] http://code.google.com/p/hotdrink/
    [5] http://code.google.com/p/hotdrink/wiki/NewWidget
    [6] https://parasol.tamu.edu/groups/pttlgroup/hotdrink/test/slider.php


    On Jan 21, 2012, at 1:56 PM, Kenneth G. Franqueiro wrote:

    While I haven't had a chance to look at the TodoMVC example yet, from
    what I saw when I was researching the dojox/mvc package a bit, I
    somewhat agree with Sasha's sentiment regarding which aspects of Dojo
    really deserve the spotlight for promoting separation of concerns
    (particularly dojo/store).

    The vibe I got from the dojox/mvc package is that it's not so much about
    separation of concerns, and a lot more about binding them together. It
    felt rather heavy (with all the Statefuls and watches it hooks up), and
    *far* too reliant on declarative markup. While I realize that
    templating is usually a part of these frameworks, I sort of feel that
    the most scalable applications built using Dojo lean on declarative
    markup as little as possible (other than for widget templates). The
    only piece of dojox/mvc that looked particularly conducive to
    programmatic use to me was the Generate module, but that seemed somewhat
    limited in usefulness currently, and it still creates declarative markup
    to be run through the parser - meaning it's actually even heavier!

    Admittedly though, I'm rather uninitiated to DojoX MVC (and relatively,
    to MVC frameworks in general), so maybe my concerns don't make a whole
    lot of sense. I do realize that the package lends itself to certain
    types of cases and could significantly expedite the process for said
    cases. I guess my premature-optimization OCD just quickly gets the
    better of me. I suppose maybe the project I was potentially looking at
    it for didn't seem like the type to significantly reap the benefits from
    the full feature set DojoX MVC provides, to justify the weight.

    I'm sorry if this sounds like I'm raining on the parade. It'd be great
    if we can improve DojoX MVC's image by addressing some of these concerns
    though.

    Thanks,
    --Ken

    On 1/21/2012 1:15 PM, Sasha Firsov wrote:

    Hi James,


    /Newer toolkits (Backbone, Spine) really promote their MVC support and

    I'm not sure many of our users know we can do the same.

    /

    I would not get too excited on Backbone or Spine. Those are not samples

    of good design and clear mind. But agree, they are good in brainwash

    playing with MVC words. I sincerely hope that we would not do same.


    DojoX MVC is just separate package which does not reflect the MVC power

    of other components. Instead I would point to dojo store(M),

    TreeStoreModel(C), dijit.Tree(V) as a good MVC sample. Unfortunately

    the naming convention in dojo does not match popular architectural

    terms. Another issue that not all components are fitting to same MVC

    delivery chain.

    I had in mind to create reusable controller out of TreeStoreModel and

    use it for dojo.store to [tab, accordion, form,...] chaining. With a

    goal to keep data in hierarchical tree structure keeping in sync.

    DojoX MVC is not best candidate just because less coherent with existing

    dijits :(


    Sasha




    _______________________________________________

    dojo-contributors mailing list

    dojo-contributors at mail.dojotoolkit.org

    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

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



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

    --
    Ed Chatelain

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

    --
    Regards,
    James Thomas

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120201/ba0721c6/attachment.htm
  • Ed Chatelain at Feb 1, 2012 at 4:11 pm
    Thanks Bill,
    I wish you had time for the MVC discussion too :)
    I found a bindingtest.zip from Stephen Chung, but it is not in a runnable
    state, (the amd support changed since it was written). I can try to get it
    running again to see what he had, or I can share it with anyone else who
    would like to take a look at it.


    2012/2/1 Bill Keese <bill at dojotoolkit.org>
    I wish I had time to keep up with the whole MVC discussion.

    As far as "something lighter", a long time ago Stephen Chung had made an
    alternate suggestion of an API to bind any obj1.attr1 to another
    obj2.attr2. It was at http://www.mingleplace.com/test/bindingtest.html but
    unfortunately that page disappeared.
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    --
    Ed Chatelain
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120201/45ae435f/attachment.htm
  • Mark Wubben at Jan 22, 2012 at 8:33 am

    On 21 Jan 2012, at 15:40, James Thomas wrote:
    * Extend StatefulModel API for arrays

    Dealing with arrays was one of my main "pain points". It would be nice to have convenience methods like "push", "pop", for modifying arrays rather than having to use "add", "remove" with explicit array indices. Adding a new todo item meant having to explicitly include new list position as an argument which seems a bit unintuitive to me (https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/app.js#L89).

    Removing a series of elements from an array (clearing all completed todos) was painful as you can only remove the elements by explicit index and we have to deal with the remaining list indices left-shifting each time we remove an element (https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/app.js#L61-78). Also found "bindInputs" wouldn't trigger on modifying array elements, had to fall back to "watch" https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/model/TodoModel.js#L60

    Would be nice to mirror Backbone's "Collection" model class by having our own "StatefulArray" class with the usual functions for operating on arrays?
    I have such a class in Eyebrow, indeed called StatefulArray. It emits splice, length and empty events upon which the reactive behavior is based.
  • Ed Chatelain at Jan 26, 2012 at 2:39 pm
    Hi James,
    Thanks again for the comments below, more inline.
    Ed

    2012/1/21 James Thomas <jthomas.uk at gmail.com>
    I recently spent some time creating Dojo's entry (
    https://github.com/jthomas/todomvc) for the TodoMVC project (
    http://addyosmani.github.com/todomvc/) with help from Ed Chatelain and
    Ben Hockey. Never having used DojoX MVC before, I kept notes on issues
    encountered creating the application to provide some feedback on using the
    module to build a simply MVC application.
    *
    *
    *Overall, it worked really well and I definitely think we need to
    publicise this aspect of the toolkit much more.* *Newer toolkits
    (Backbone, Spine) really promote their MVC support and I'm not sure many of
    our users know we can do the same. *

    ** Extend StatefulModel API for arrays*

    Dealing with arrays was one of my main "pain points". It would be nice to
    have convenience methods like "push", "pop", for modifying arrays rather
    than having to use "add", "remove" with explicit array indices. Adding a
    new todo item meant having to explicitly include new list position as an
    argument which seems a bit unintuitive to me (
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/app.js#L89
    ).

    Removing a series of elements from an array (clearing all completed todos)
    was painful as you can only remove the elements by explicit index and we
    have to deal with the remaining list indices left-shifting each time we
    remove an element (
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/app.js#L61-78).
    Also found "bindInputs" wouldn't trigger on modifying array elements, had
    to fall back to "watch"
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/model/TodoModel.js#L60

    Would be nice to mirror Backbone's "Collection" model class by having our
    own "StatefulArray" class with the usual functions for operating on arrays?
    I have created this ticket to add better array support which I will plan to
    add in 1.8, I will also add information to the MVC 1.8 Specification.

    ** Support composite values as part of model declaration*

    We had two attributes in the model, "completed" and "remaining", that were
    composite attributes (calculated from other values). Would be nice if the
    StatefulModel supported declare these in meta-data for the StatefulModel
    rather than having to manually execute the mvc.bind method during
    instantiation.
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/model/TodoModel.js#L44-46
    *
    * **
    ** Allow binding to inner attributes updates in child models from the
    parent. *
    *
    *
    Whenever the user modifies the checkbox, that todo item's model boolean
    value is updated and we can to re-calculate the "completed" and "remaining"
    model values. I couldn't find a way to bind to any changes to child model
    inner attributes from the parent "todo" model. The code has to manually
    bind to the "isDone" attribute on every child model, rather than listening
    for changes to the parent model array. This is more of a stretch goal but
    it would have been useful to have changes "bubble" up to the parent models.
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/model/TodoModel.js#L68-70

    In 1.8 we are adding support for a converter to be attached to a binding,
    so it would be possible to set up a converter which would be able to update
    the completed and remaining values whenever one of the items is changed,
    would that eliminate the need for supporting composite values and event
    bubbling?

    ** Conditionals in view templates*
    *
    *
    If the user has completed some tasks and/or has some remaining, the view
    should show the "stats" element at the bottom of the page. Most of the
    other library examples used conditional logic in their templates to achieve
    this but I had to bind to a model change, manually toggling CSS classes
    representing the state.
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/app.js#L96-99

    I was under the assumption that DojoX DTL was pretty much dormant, have we
    got any plans to include this functionality in our dijit templating code in
    2.0 or would fall under an MVC improvement?

    *Reviewing the 1.8 MVC specification (
    https://docs.google.com/document/d/1ejZlUwySI0q3n3scInw30drHa7no7Zm-WSZqtYx5scE/edit),
    there are already plans to fix some issues I encountered...*

    ** Binding to any widget property, not just "value".*

    Hit this issue trying to bind the dijit.form.CheckBox widgets to the
    StatefulModel, due to the "value" and "checked" attributes.

    ** Docs, Demo App, Integration with DojoX App*

    Found documentation sufficient for DojoX MVC but I did read the MVC code
    before starting so I'm probably not that representative of a new user.

    Hopefully this application will provide a good reference for getting
    started with DojoX MVC, but it'd be nice to have a less trivial example and
    also show integration with DojoX App and other parts of the toolkit.

    Regards,
    James Thomas

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

    --
    Ed Chatelain
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120126/88285bf8/attachment.htm
  • Sasha Firsov at Jan 26, 2012 at 3:59 pm
    Ed,
    If you are thinking about support for more complex than flat object with
    attributes model, than it worth to discover full-blown hierarchical data
    support. Backbone.Collection unfortunately does not fit there. But XML
    store does well. Same could be done for JSON store with accent on
    hierarchy selectors(a-la XPath)
    Flat arrays is definitely evolution in comparison to simple object, but
    way less than we already have in place with store objects.

    Sasha

    On 1/26/2012 11:39 AM, Ed Chatelain wrote:


    Would be nice to mirror Backbone's "Collection" model class by
    having our own "StatefulArray" class with the usual functions for
    operating on arrays?

    I have created this ticket to add better array support which I will
    plan to add in 1.8, I will also add information to the MVC 1.8
    Specification.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120126/3e228589/attachment.htm
  • Bill Keese at Feb 2, 2012 at 2:33 am
    I downloaded from github and was able to run todomvc/todo-example/dojo/.
    I checked out the code too. This is a fairly simple application... I'm
    wondering if MVC is getting you anything here, compared to just using a
    store?

    2012/1/22 James Thomas <jthomas.uk at gmail.com>
    I recently spent some time creating Dojo's entry (
    https://github.com/jthomas/todomvc) for the TodoMVC project (
    http://addyosmani.github.com/todomvc/) =
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120202/709cae06/attachment.htm
  • Ed Chatelain at Feb 28, 2012 at 9:43 am
    Akira Sudoh and I have made many updates to dojox.mvc, mostly based upon
    the comments and suggestions in this email chain, as well as suggestions
    which Stephen Chung had made previously.

    The latest dojox.mvc code is being developed in github, and is regularly
    merged into the dojo svn (trunk).
    You can find the code in github here: https://github.com/edchat/dojox_mvc

    Feel free to make comments here, or in the "dojox.mvc 1.8 Specification"
    document
    https://docs.google.com/document/d/1ejZlUwySI0q3n3scInw30drHa7no7Zm-WSZqtYx5scE/edit,
    or in github, or in trac as you prefer.

    Support for multiple attributes (attributes in addition to value) has been
    added with dojox.mvc.at and dojox.mvc.sync, along with support for multiple
    attributes there is also support for binding in one direction
    (dojox.mvc.toor dojox.mvc.from) or bi-directional (dojox.mvc.both
    which is the default),
    and support for a converter (dojox.mvc.sync.converter) has also been added.

    Array support has been added with dojox.mvc.StatefulArray and
    dojox.mvc.ListController, which in addition to supporting array functions
    on the model also has support for a cursor to make it easier to work with a
    Master-Detail pattern.

    The dojox.mvc.StatefulModel has been deprecated in favor of a lighter
    weight model (dojox.mvc.getStateful) which can be as simple as a
    dojo.Stateful, or it can be used with the controllers to support arrays,
    edit (reset/commit), and stores.

    You can see examples of all of the above in the dojox/mvc/tests folder.

    Thanks,
    Ed Chatelain

    2012/1/21 James Thomas <jthomas.uk at gmail.com>
    I recently spent some time creating Dojo's entry (
    https://github.com/jthomas/todomvc) for the TodoMVC project (
    http://addyosmani.github.com/todomvc/) with help from Ed Chatelain and
    Ben Hockey. Never having used DojoX MVC before, I kept notes on issues
    encountered creating the application to provide some feedback on using the
    module to build a simply MVC application.
    *
    *
    *Overall, it worked really well and I definitely think we need to
    publicise this aspect of the toolkit much more.* *Newer toolkits
    (Backbone, Spine) really promote their MVC support and I'm not sure many of
    our users know we can do the same. *

    ** Extend StatefulModel API for arrays*

    Dealing with arrays was one of my main "pain points". It would be nice to
    have convenience methods like "push", "pop", for modifying arrays rather
    than having to use "add", "remove" with explicit array indices. Adding a
    new todo item meant having to explicitly include new list position as an
    argument which seems a bit unintuitive to me (
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/app.js#L89
    ).

    Removing a series of elements from an array (clearing all completed todos)
    was painful as you can only remove the elements by explicit index and we
    have to deal with the remaining list indices left-shifting each time we
    remove an element (
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/app.js#L61-78).
    Also found "bindInputs" wouldn't trigger on modifying array elements, had
    to fall back to "watch"
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/model/TodoModel.js#L60

    Would be nice to mirror Backbone's "Collection" model class by having our
    own "StatefulArray" class with the usual functions for operating on arrays?

    ** Support composite values as part of model declaration*

    We had two attributes in the model, "completed" and "remaining", that were
    composite attributes (calculated from other values). Would be nice if the
    StatefulModel supported declare these in meta-data for the StatefulModel
    rather than having to manually execute the mvc.bind method during
    instantiation.
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/model/TodoModel.js#L44-46
    *
    *
    ** Allow binding to inner attributes updates in child models from the
    parent. *
    *
    *
    Whenever the user modifies the checkbox, that todo item's model boolean
    value is updated and we can to re-calculate the "completed" and "remaining"
    model values. I couldn't find a way to bind to any changes to child model
    inner attributes from the parent "todo" model. The code has to manually
    bind to the "isDone" attribute on every child model, rather than listening
    for changes to the parent model array. This is more of a stretch goal but
    it would have been useful to have changes "bubble" up to the parent models.
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/model/TodoModel.js#L68-70

    ** Conditionals in view templates*
    *
    *
    If the user has completed some tasks and/or has some remaining, the view
    should show the "stats" element at the bottom of the page. Most of the
    other library examples used conditional logic in their templates to achieve
    this but I had to bind to a model change, manually toggling CSS classes
    representing the state.
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/app.js#L96-99

    I was under the assumption that DojoX DTL was pretty much dormant, have we
    got any plans to include this functionality in our dijit templating code in
    2.0 or would fall under an MVC improvement?

    *Reviewing the 1.8 MVC specification (
    https://docs.google.com/document/d/1ejZlUwySI0q3n3scInw30drHa7no7Zm-WSZqtYx5scE/edit),
    there are already plans to fix some issues I encountered...*

    ** Binding to any widget property, not just "value".*

    Hit this issue trying to bind the dijit.form.CheckBox widgets to the
    StatefulModel, due to the "value" and "checked" attributes.

    ** Docs, Demo App, Integration with DojoX App*

    Found documentation sufficient for DojoX MVC but I did read the MVC code
    before starting so I'm probably not that representative of a new user.

    Hopefully this application will provide a good reference for getting
    started with DojoX MVC, but it'd be nice to have a less trivial example and
    also show integration with DojoX App and other parts of the toolkit.

    Regards,
    James Thomas

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

    --
    Ed Chatelain
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120228/051a621b/attachment.htm
  • James Thomas at Mar 4, 2012 at 4:16 pm
    These improvements look great, I'll have to update the TodoMVC entry with
    the latest features and see how it goes...

    2012/2/28 Ed Chatelain <ed.chatelain at gmail.com>
    Akira Sudoh and I have made many updates to dojox.mvc, mostly based upon
    the comments and suggestions in this email chain, as well as suggestions
    which Stephen Chung had made previously.

    The latest dojox.mvc code is being developed in github, and is regularly
    merged into the dojo svn (trunk).
    You can find the code in github here: https://github.com/edchat/dojox_mvc

    Feel free to make comments here, or in the "dojox.mvc 1.8 Specification"
    document
    https://docs.google.com/document/d/1ejZlUwySI0q3n3scInw30drHa7no7Zm-WSZqtYx5scE/edit,
    or in github, or in trac as you prefer.

    Support for multiple attributes (attributes in addition to value) has been
    added with dojox.mvc.at and dojox.mvc.sync, along with support for
    multiple attributes there is also support for binding in one direction (
    dojox.mvc.to or dojox.mvc.from) or bi-directional (dojox.mvc.both which
    is the default), and support for a converter (dojox.mvc.sync.converter) has
    also been added.

    Array support has been added with dojox.mvc.StatefulArray and
    dojox.mvc.ListController, which in addition to supporting array functions
    on the model also has support for a cursor to make it easier to work with a
    Master-Detail pattern.

    The dojox.mvc.StatefulModel has been deprecated in favor of a lighter
    weight model (dojox.mvc.getStateful) which can be as simple as a
    dojo.Stateful, or it can be used with the controllers to support arrays,
    edit (reset/commit), and stores.

    You can see examples of all of the above in the dojox/mvc/tests folder.

    Thanks,
    Ed Chatelain

    2012/1/21 James Thomas <jthomas.uk at gmail.com>
    I recently spent some time creating Dojo's entry (
    https://github.com/jthomas/todomvc) for the TodoMVC project (
    http://addyosmani.github.com/todomvc/) with help from Ed Chatelain and
    Ben Hockey. Never having used DojoX MVC before, I kept notes on issues
    encountered creating the application to provide some feedback on using the
    module to build a simply MVC application.
    *
    *
    *Overall, it worked really well and I definitely think we need to
    publicise this aspect of the toolkit much more.* *Newer toolkits
    (Backbone, Spine) really promote their MVC support and I'm not sure many of
    our users know we can do the same. *

    ** Extend StatefulModel API for arrays*

    Dealing with arrays was one of my main "pain points". It would be nice to
    have convenience methods like "push", "pop", for modifying arrays rather
    than having to use "add", "remove" with explicit array indices. Adding a
    new todo item meant having to explicitly include new list position as an
    argument which seems a bit unintuitive to me (
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/app.js#L89
    ).

    Removing a series of elements from an array (clearing all completed
    todos) was painful as you can only remove the elements by explicit index
    and we have to deal with the remaining list indices left-shifting each time
    we remove an element (
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/app.js#L61-78).
    Also found "bindInputs" wouldn't trigger on modifying array elements, had
    to fall back to "watch"
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/model/TodoModel.js#L60

    Would be nice to mirror Backbone's "Collection" model class by having our
    own "StatefulArray" class with the usual functions for operating on arrays?

    ** Support composite values as part of model declaration*

    We had two attributes in the model, "completed" and "remaining", that
    were composite attributes (calculated from other values). Would be nice if
    the StatefulModel supported declare these in meta-data for the
    StatefulModel rather than having to manually execute the mvc.bind method
    during instantiation.
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/model/TodoModel.js#L44-46
    *
    *
    ** Allow binding to inner attributes updates in child models from the
    parent. *
    *
    *
    Whenever the user modifies the checkbox, that todo item's model boolean
    value is updated and we can to re-calculate the "completed" and "remaining"
    model values. I couldn't find a way to bind to any changes to child model
    inner attributes from the parent "todo" model. The code has to manually
    bind to the "isDone" attribute on every child model, rather than listening
    for changes to the parent model array. This is more of a stretch goal but
    it would have been useful to have changes "bubble" up to the parent models.
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/model/TodoModel.js#L68-70

    ** Conditionals in view templates*
    *
    *
    If the user has completed some tasks and/or has some remaining, the view
    should show the "stats" element at the bottom of the page. Most of the
    other library examples used conditional logic in their templates to achieve
    this but I had to bind to a model change, manually toggling CSS classes
    representing the state.
    https://github.com/jthomas/todomvc/blob/master/todo-example/dojo/js/todo/app.js#L96-99

    I was under the assumption that DojoX DTL was pretty much dormant, have
    we got any plans to include this functionality in our dijit templating code
    in 2.0 or would fall under an MVC improvement?

    *Reviewing the 1.8 MVC specification (
    https://docs.google.com/document/d/1ejZlUwySI0q3n3scInw30drHa7no7Zm-WSZqtYx5scE/edit),
    there are already plans to fix some issues I encountered...*

    ** Binding to any widget property, not just "value".*

    Hit this issue trying to bind the dijit.form.CheckBox widgets to the
    StatefulModel, due to the "value" and "checked" attributes.

    ** Docs, Demo App, Integration with DojoX App*

    Found documentation sufficient for DojoX MVC but I did read the MVC code
    before starting so I'm probably not that representative of a new user.

    Hopefully this application will provide a good reference for getting
    started with DojoX MVC, but it'd be nice to have a less trivial example and
    also show integration with DojoX App and other parts of the toolkit.

    Regards,
    James Thomas

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

    --
    Ed Chatelain

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

    --
    Regards,
    James Thomas
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120304/7454fa01/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedJan 21, '12 at 10:40a
activeMar 4, '12 at 4:16p
posts15
users7
websitedojotoolkit.org

People

Translate

site design / logo © 2021 Grokbase