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

Bill Keese bill at dojotoolkit.org
Fri Oct 1 03:07:08 EDT 2010


  We should definitely keep things simple, I'm just wondering if a store 
should have a flag to indicate which interface is supported, something 
that a widget can check before pulling any data, because it might affect 
how the widget is rendered (whether it has scroll bars, has 
next/previous buttons, etc.)   I don't know, maybe it's not necessary.

As for sorting, all stores in 1.0 support sorting, or at least (for 
example) Grid assumes so.    And no stores support sorting on 
getChildren(), that concept is new.


On 10/1/10 1:06 PM, Kris Zyp wrote:
>
>
> On 9/30/2010 4:31 PM, Bill Keese wrote:
>> Remember that widgets need to be able to interface to any store.   
>> This will make it very difficult.   The interface is:
>>
>> getChildren() may or may not implement queryOptions, so you cannot 
>> depend on that feature.    Furthermore, there's no way to know if the 
>> feature exists except by calling getChildren() with start/length and 
>> checking if the returned array contains "total".
>
> That's correct, the code would always call getChildren() with the 
> query options, and if total wasn't available it would check the 
> length. Basically (results.total || results.length) which doesn't seem 
> too terrible.


>> I'm not sure if there's any way at all to tell if the sort parameter 
>> works or not?
>>
> Has there ever been a way to tell if a store doesn't support sort? 
> With existing data stores, if sorting is implementing, you just don't 
> get your items sorted. Also, the implementation that is likely to not 
> have sort implemented is children array approach, but that approach is 
> designed for order data, the data that most likely should *not* be 
> sorted. Generally unordered items are favorable to sorting, ordered 
> items already have an order and shouldn't be sorted. If someone else 
> wants the complexity of both, they are certainly can implement it, but 
> we have make the common case as simple as possible.
> Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101001/3ff2b106/attachment-0001.htm 


More information about the dojo-contributors mailing list