Hey Antranig, Glad it looks like it has some potential for re-use :)
Yes, you're right that the batched pager code doesn't really deal with asynchrony. In typical use, we've paired the batched pager component with some sort of complex data-fetching subcomponent. Typically the data component is initialized and fetches an initial data set prior to creating the pager component. The data and data length functions generally are wired to call an internal method of the parent component or a public method of the subcomponent that reports on that already-collected data. We use this setup in part because we typically want to add more complex handling like caching to the data-fetching operations. For example, we generally keep all collected data around in-memory so that if a user pages forwards and then backwards the browser doesn't have to re-fetch data that was already collected. I'm not sure I know where the code is for our original, most well-developed use case for the batched pager. There's a more basic implementation in the Jasig email preview portlet: https://source.jasig.org/portlets/email-preview/trunk/src/main/webapp/js/email-browser.js. That portlet is in its infancy, so the implementation isn't especially sophisticated (and has some edge cases like not including logic to update the data length when new emails arrive between refreshes). It looks like in this case we're using a synchronous request during the data refresh. In the UI, we typically display some sort of loading message until the component is fully loaded, and display the same message during refresh attempts. Happy to answer any more questions that come up. :) - Jen On Aug 14, 2010, at 11:34 PM, Antranig Basman wrote: > Hi there Jen - thanks for circulating your work on the "batched pager" > configuration for our "old-style" pager component :) Sadly, pressure of work > has meant that the "new-style pager" is still half-baked in a branch > somewhere so I am seeing your patch at > https://source.fluidproject.org/svn/incubator/batched-pager/trunk/js/batched-pager.js > as a valuable starting point for a bit of work I am currently doing with > integrating the pager into another project which requires server-side paging. > The patch looks ingenious and shows a good appreciation of the planned > architecture (however half-baked :P) of the "old pager" - one question does > occur to me which is that unless I am missing something the patch doesn't > seem to deal with the issue of asynchrony. The configuration options > "dataFunction" and "dataLengthFunction" appear to be invoked in the patch > using a synchronous style, and I guess if they issue any I/O must also do it > synchronously? What does the UI show in this case, is it just blocking on the > click event that is at the base of the current stack? Or could you find a way > to implement these configuration functions in your integration that operated > asynchronously? > If you could show me a little more of how you used this patch in practice > without revealing any code you're not meant to, I'd appreciate it - > Cheers, > Antranig. > _______________________________________________________ > fluid-work mailing list - [email protected] > To unsubscribe, change settings or access archives, > see http://fluidproject.org/mailman/listinfo/fluid-work _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
