[dojo-contributors] TreeGrid enhancement for 1.6 - lazy loading for children rows

Evan Huang evanhuangwei at gmail.com
Sat Oct 2 08:50:20 EDT 2010


Sorry guys, seems I've brought some confusions here, actually I meant still
keeping geChildren() on model (the way a newer in-progress patch works for
#11716),

And for 2.0, this logic can still work well:
1. We have a dojo.store() providing simple, universal api - query(), which
supports paging, sorting etc.
2. Use model for some specific situations e.g. for Tree

More specific for Tree/TreeGrid:
- Different types of Tree models can deal with various reqts(e.g. lazy
loading & paging children) still with the same getChildren() API - though
may with different parameters

- When store.query() used by model.getChildren() no matter with children
paged or not, the returned "total" property always == number of children
under the same requested parent

- For the 2nd data hierarchy Kris mentioned - flatten items each with parent
reference, we can simply use another type of model

- Ideally we need to make the lazy loading as a mixin so that it can simply
applied across models targeting various data structure

- Don't think there will be a way to tell if a store supports sorting or
what kind of sorting,  tree model will simply pass sorting info to
store.query() if needed, we'll depend more on store how sorting works, e.g.
for TreeGrid, we'd like to add a feature of "sorting chldren[]" - mean only
sorting(single|nested) children under the same parent - currently not
supported by any stores in dojo.data/dojox/data


Thanks!

- Evan













----------------------------------------------------
This was my thinking originally too, which is why TreeStoreModel is
separate from the store.   I thought of the store as the database, and
getChildren() as part of the app.

For example, using oracle's EMP-DEPT (employees and departments) sample
database , one app might have a tree composed of just departments,
another might have a tree of just employees, and a third app might have
a tree of departments and employees.   The database is always the same
but the getChildren() method (for a given department) is different.

On 10/2/10 6:33 AM, Jonathan Bond-Caron wrote:
> On Fri Oct 1 03:21 PM, Kris Zyp wrote:
>>
>> What is the advantage to having extra methods on a model instead of
>> the store?
>>
> - The main benefit would be to make the store api simpler to use and learn
/
> design goal #1 ;)
>
> What I mean by simpler is ~ fewer methods but provides the same
> functionality, so moving getChildren() and idProperty somewhere else.
>
> - For other benefits, I'll find time and update Evan's TreeGrid patch with
a
> couple of examples
>
> It's about separating two different concepts that getChildren() depends on
>
> (a) the data storage (how to get child items) and (b) the data model
(how/in
> what way an item and its children are stored).
>
> When you know both (a) and (b), you can write a better/more efficient
> 'getChildren()' method.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101002/8880b0f4/attachment-0001.htm 


More information about the dojo-contributors mailing list