[dojo-contributors] dijit 2.0 plan

Rahul Akolkar rahul.akolkar at gmail.com
Sun Oct 3 21:59:20 EDT 2010


OK, I have registered [1] for DDD 2010 on eventbrite.

I'd like to get an hour if possible on one of the two days to go over
some of the MVC work, do some demos to illustrate how its being used
and sketch out a plan in place of the placeholder thats in the current
Dijit 2.0 document [2].

Later, we can also brew some mvc into our dojo.beer :-)

-Rahul

[1] As an aside, I had to elevate myself to a Dojo Commiter (sic)
ticket as I didn't see a non-committer option there.
[2] https://docs.google.com/View?id=ddjgq3wx_14fw9wt7cq#MVC_architecture_8118856269866228



On Sun, Sep 12, 2010 at 9:45 PM, Bill Keese <bill at dojotoolkit.org> wrote:
> That sounds great. Sorry I didn't respond to your earlier mail, but basically I want to talk about the ideas more before deciding what goes into 2.0, and how.
>
> On 2010/09/13, at 4:38, Rahul Akolkar <rahul.akolkar at gmail.com> wrote:
>
>> WRT my comments below, it seems to me that DDD would be a great chance
>> for us to discuss some of this MVC work and go through examples of
>> what Charlie and I have worked on. Maybe a MVC patterns discussion
>> session, perhaps as part of larger dijit 2.0 discussions? WDYT?
>>
>> If there is interest, I'll try to get the travel arrangements done in
>> time, register etc.
>>
>> -Rahul
>>
>>
>> On Wed, Sep 8, 2010 at 10:40 AM, Rahul Akolkar <rahul.akolkar at gmail.com> wrote:
>>> On Sat, Aug 28, 2010 at 8:34 AM, Bill Keese <bill at dojotoolkit.org> wrote:
>>>>  At next week's meeting we are going to talk about dijit 2.0. I've
>>>> written a prospective plan, nothing set in stone but open for discussion
>>>> (in the meeting or on this mailing list):
>>>>
>>>> https://docs.google.com/View?id=ddjgq3wx_14fw9wt7cq
>>>>
>>>
>>> For the TODO listed in Section 6.7 on MVC Architecture, the following
>>> is a compiled list that summarizes the feature set we have discussed
>>> in those thread(s) here. I've put these into 4 buckets, and where
>>> items straddle more than one of those 4 concerns, they are placed in
>>> the bucket that has most apparent affinity to them.
>>>
>>> --8<--
>>>
>>> MVC Architecture and Patterns - Features
>>>
>>> Model:
>>>  * Build on dojo.Stateful
>>>  * Support hierarchical data
>>>   - object properties
>>>   - arrays
>>>  * Support extensible meta-data properties
>>>   - required, readonly, relevance, validity etc.
>>>  * Support data dependencies and calculates
>>>  * Talk to dojo.data (1.x and 2.x) stores
>>>  * Data submission patterns
>>>
>>> View:
>>>  * Model binding behavior (currently implemented as two mixins)
>>>   - Data model binding (watch changes, update view)
>>>   - Data properties support
>>>     ~ Combine with any existing dijit notions of properties (eg. validity)
>>>  * Nested binds via parent data binding
>>>  * Containers
>>>   - Grouping widgets
>>>   - Repeating UIs
>>>   - Form or view generation
>>>
>>> Controller:
>>>  * Bind expressions (currently property name of parent)
>>>   - Expression language
>>>  * Dependency graphs -- à la property models
>>>  * Setting parent data binding context where it isn't the logical / DOM parent
>>>
>>> Patterns:
>>>  * Examples: master detail, search list, validating form, list to list
>>>
>>> --8<--
>>>
>>> In terms of work items and dijit 2.0 integration, it would probably
>>> make sense to phase in some of the implementation (we already have a
>>> functioning prototype that does some of the above things). There is a
>>> logical progression for building in such a feature set, which may
>>> translate into a roadmap as follows (though not all items have
>>> strictly linear implementation dependencies, some items may be done in
>>> parallel):
>>>
>>> --8<--
>>>
>>> MVC Architecture and Patterns - Roadmap
>>>
>>> (1) Add a stateful model that can encapsulate data concerns for one or
>>> more forms
>>> (2) Add the ability for various dijits to bind to parts of the above model
>>>    ~ Currently implemented as a mixin
>>> (3) Add the ability for the data binds to also communicate data
>>> property information (along with values)
>>>    ~ Currently implemented as another mixin
>>> (4) Expand on the model implementation
>>>    ~ Ability to specific data dependencies and calculates
>>>    ~ Add simple patterns for model data submission
>>> (5) Add containers for producing composite model-bound UIs (group,
>>> repeat, generate etc.)
>>> (6) Investigate and incorporate expression language support for bind
>>> expressions, and how such may be leveraged for more sophisticated
>>> dependency graph updates
>>> (7) Build pattern examples / sample apps to demonstrate usage
>>> (documentation, guides and smaller examples best done along with 1
>>> through 6 ofcourse).
>>>
>>> --8<--
>>>
>>> Comments welcome. What do you think? Should we include some of the
>>> above in the dijit 2.0 document?
>>>
>>> -Rahul
>>>


More information about the dojo-contributors mailing list