Re: dojo.data - simple paging example

> We've been talking about what the datastore API should look like  
> for that use case.  One option is for the GUI code make separate  
> calls to store.find() each time the user pages forward, with each  
> call getting a new result object, one result object per page of  
> data.  Another option is for the the GUI code make one initial call  
> to store.find() to get a single result object, and then make  
> separate calls to result.forEach(), each time asking to loop over  
> just a portion of the virtual result set.  The question is, should  
> we encourage just that first option, or just the second, or allow  
> for both?


I'm not opposed to having both options, but I like the single-result  
set approach presented here.

In writing these sorts of apps, especially with async queries, it  
seems like it would be advantageous to have a single result set that  
the app author deals with rather than having to manage multiple  
sets.  For example, it's pretty common to load data in bigger chunks  
than you want to display -- that way "next page" can be instantaneous  
(although the next page after *that* may take a while -- we take what  
we can get).  Presumably, it should be pretty easy to make a display- 
tabley-widget thing that could implement this automatically --  
whenever it displays a page, it goes and fetches the data for the  
next page in the background.

Or you might be able to teach your tabley-widget that some items may  
be in memory, while some aren't.  So if you have half of the next  
page of things, it displays the half that it has, with a little  
"loading..." message for the ones it can't find yet.  Then when those  
load, their loading messages replaced in the table with real data.   
This type of thing is great for UI, because the user can see that  
something is happening immediately, and results  can come back in as  
they are ready.

It seems like the single result set is almost a must for the  
"infinite scrollbar" case -- managing multiple result sets would be a  
real pain.

There is another UI paradigm that this is also great for -- where you  
start with a small table (say 10 items), then the last item says  
"more...". They click the button and those items load underneath the  
set already present.  I did a quick mockup of that [can you tell I'm  
procrastinating?], enclosed -- drop the files in the same folder as  
Brian's example to see it.

Finally, one thing that I'd expect to see in the params available to  
the method forEach() calls is the index in the result set of the item  
being iterated on.      Without this, I was dependent on the server  
setting the "identity" column.  If it doesn't make sense to pass it  
as a parameter to the function, perhaps there can be a flag that  
indicates that an index should appear in the result set data?

Fun stuff!

cheers
O

additive_paging.zip
Description: Zip archive

-------------------------
Whenever I despair, I remember that the way of truth and love has  
always won. There may be tyrants and murderers, and for a time, they  
may seem invincible, but in the end, they always fail. Think of it:  
always.  -- Mohandas K. Ghandi


On Oct 1, 2006, at 6:49 PM, Brian Douglas Skinner wrote:

> For people intested in the dojo.data design...
>
> We've been talking about how we want scrolling and paging to work  
> for large result sets.  If there's a large result set, the UI might  
> allow the user to go from page to page through the results.  Or the  
> UI might have a large scroll-view, and incrementally load data as  
> the user scrolls.
>
>
> As a quick exercise to make all of this more concrete, this weekend  
> I wrote some test code that uses the second option (one result  
> object and multiple calls to result.forEach()).  The test code uses  
> the Yahoo web services APIs to run a Yahoo query, and then you can  
> page through the results.
>
> I'm including the code as an attachment here, if you want to play  
> around with it.  To use it, first create a new "yahoo" folder in  
> your dojo tests/data directory:
>   trunk/tests/data/yahoo
> Unzip the attachment, drop the contents into the yahoo folder, and  
> open the "paging_example.html" file.
>
> If you're looking at the code, the place to start is  
> paging_example.js.  There's a method runSearch(), which has the  
> call to store.find(), and there's a method displayPage(), which has  
> the call to result.forEach().
>
> Let me know if you run into problems, and I can try sending the  
> files in some other format.
>
> :o) Skinner
>
>
>
>
> <paging_example.zip>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors@xxxxxxxxxxxxxxx
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors

_______________________________________________
dojo-contributors mailing list
dojo-contributors@xxxxxxxxxxxxxxx
http://dojotoolkit.org/mailman/listinfo/dojo-contributors