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

Bill Keese bill at dojotoolkit.org
Fri Oct 1 23:48:28 EDT 2010


  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.
>
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors


More information about the dojo-contributors mailing list