[dojo-contributors] TreeGrid enhancement for 1.6 - lazy loading for children rows
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
More information about the dojo-contributors