Best Practice when to use BufferedStore versus normal Store

[TerryB]

I've started moving away from PagingToolbar because so many of my master Store requests can involve server side filtering than can not be done using SQL over the primary master file. That keeps the Paging from working because Start can not pass in the RRN for Fetch. But not clear to me on when/whether to use BufferedStore with Infinite Scrolling. Do you only worry about when you can see a visual delay in the load of the Grid? Or are their other reasons not obvious that BufferedStore is way to go? App I'm doing now has about 1000 records it returns if no filters are applied. It visually appears to load as quickly as it did when PagingToolbar was used. These apps are Intranet but some WAN usage over 10Mbs links and can also be used via VPN over internet. I assume that needs to be taken into account also.

[sean.lanktree]

Hi Terry - I am not entirely clear on this. You are unable to filter your results using SQL?

[TerryB]

Correct. After I use SQL to do the main fetch, and apply whatever filters I can during the SQL statement build, I many times have to use RPG I/O to apply sophisticated filters before I load record to array and return the JSON response. So the SQL cursor/fetch logic does not work when the paging toolbar passes in the Start number to be used as RRN when sending out new page. Only a few applications have this problem, I can usually create join logicals to do all the filtering. But some apps that is impossible, you can not join, you need business logic.

[TerryB]

Infinite scrolling is kind of nice anyway for users. Just not sure when to make transition from normal Store to this BufferedStore.

[sean.lanktree]

Hi Terry - you would have the same problem with infinite scrolling as that makes the same calls as a paging toolbar would. If you have less than say 5000 results it would be fine to just load the whole list initially and let the front-end do any filtering.

[TerryB]

Hmmmm. Tells me I really don't understand BufferedStore yet. What gives me the problem is the server side code which is returning JSON reply. It has a DOW like:

dow SqlGetRecord(Records) and count < post_Limit;

When I remove PagingToolbar, my loop is just: dow SqlGetRecord(Records) and I send all records back that pass the RPG filters in the DOW loop. It sounds like in your reply, if I use BufferedStore I would still have to code the DOW loop using Limit, just like I do with PagingToolbar. Which means the passed in Start would have exact same problem.

I thought from reading API guide the RPG returned all the records but they were cached outside of DOM, then BufferedStore retrieved them without further server calls. But now that I write this, it does sound somewhat ridiculous. I was interpreting DOM as what was involved in the rendering, but that the Store containing all records was cached on client. I'm guessing DOM must refer to all resources on the client side, whether rendered or not?

[sean.lanktree]

BufferedStore and infinitescroll are 2 different concepts...at least in more recent versions of Ext. Infinite scroll will call for data when it needs it based on the users scroll position. In your case, why not just return all of the data since it is only 1000 records?

[TerryB]

I am. I was just thinking ahead when that Store has 10,000 or 100,000 records. I have app over Inventory History now, which that file has 2 million records in it. Luckily this does not need filtering beyond when I build the SQL statement, I use paging toolbar. I'm just making sure I understand what to do in case I get an app like now with 10 times the records I have to return.

I think I got it Sean. Thanks for taking time to discuss!