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

Evan Huang evanhuangwei at gmail.com
Sat Oct 2 09:54:07 EDT 2010


This might be a bit off our topic, but I'm really interested in following
api in new dojo.store()
1. dojo.store.Cache
2. dojo.store.Watchable(store wrapper)

We've got similar requirements when working on new Grid/new EDG plugins,
would be terrific if they are natively supported in new store():-)

#1. Will this be a real size-limited client cache?
As we discussed in another thread previously, this could fundamentally fix a
potential issue when a widget working with sever-side store in way of lazy
loading(virtual scrolling) - currently this issue only exists in Grid since
only Grid has this happed situation - when Grid works with QueryReasStore:

- Though QueryReasStore only caches data item each time fetched e.g. 50
items by emptying all the previously fetch items,  Grid keeps all the
references to visited items so these items won't be garbage collected(they
still existed even though QueryReasStore always tries to empty them before
each fetch()).

- Eventually it turns out - QueryReasStore only have 50 items(by last
fetch), but DataGrid._by_idx[] keeps thousands(or more) references to real
data items. So memory usage may increase if user uses Grid with large data
set and keeps scrolling for a long time  -
http://trac.dojotoolkit.org/ticket/11370

So dojo.store.Cache would be an ideal solution for this



#2. This might not be a general case, but it happens when the same store
being used by multiple objects(e.g. various Grid plugins) each has it's own
logic to control/change the fetch()/query() - e.g. handle parameters
pre|post fetch/query(), filtering the returned result data ...

The typical way of mixing or inheriting won't work as they change the
parameters & methods(e.g. fetch/query()) permanently,  while we want to
minimize impact on store so it looks un-impacted to various plugins.

We still need more thoughts to ensure this were an ideal way:
- Adding a flexible store wrapper(layer) mechanism so that the same store
could be shared across various objects(e.g. Grid plugins) for different
reqts

- This approach wraps standard APIs of data store(typically
"fetch()|query()") layer by layer,  data(or parameters) are temporarily
modified or transformed in a chained manner, while independence between
wrappers(layers) still remains - since the wrapping is based on standard API
of data store.

- User can even reuse the same store out of Grid since nothing is actually
changed in store while plugins in Grid could do what they want since they
have store wrappers(layers).


Going to make a patch on this later as currently I'm mainly working on bug
fixing & new features for DataGrid/EDG/TreeGrid 1.6


Thanks!

- Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101002/4e5be979/attachment.htm 


More information about the dojo-contributors mailing list