Forum post:
http://www.sencha.com/forum/showthread.php?237492

We currently have to use a lot of workarounds to get this functionality with 4.1 and since to-one relationships are supported, it makes sense that the components (such as the grid) natively support it.

Just my 2 cents.

I love the changes to the grid though, keep up the great work!

Uncaught TypeError: Cannot call method ‘substring’ of undefined ext-all.js:18

Some confusion of terms there. There is no “buffered store plugin”. A store can be buffered with the “buffered: true” config. That is the same as before and doing this triggers buffered rendering (same as before). What is new is that a normal store (one without “buffered: true”) can be used on a grid with the bufferedrenderer grid plugin to get the same performance improvement.

When using a normal store, all of the content is loaded. This is not the case with a buffered store: it loads pages on demand (as it did previously). So unless you need the massive data set support of the buffered store, you can use a normal store and have direct access and control over the store content.

We certainly want to fix such problems. Where did you log the ticket? The forum or support?

Don, it will not be a problem to populate the whole store upfront when the application starts up, so there is no need to have a buffered store. So I will have a store with one large single page and a grid with ‘bufferedrenderer’ plugin.
I would call store.add/ store.remove when an update from the server arrives. These currently do not work properly: grid gets updated, but once I resize it, all updates are gone.I believe there is a bug somewhere in the BufferedRenderer (just filed a bug report).
I would think that it would be in the Sencha’s best interest to fix it. The number of applications with this type of functionality will only continue to grow. ‘BufferedRenderer’ is still in beta - do you think it is possible to fix it before 4.2 is released?
Thanks

By “edit” I mean “make changes client-side that need to be saved to the server”. In this case you are not really editing so much as pulling in updates from the server asynchronously. If I follow you correctly… you are not making changes client-side, just reflecting server-side changes on the client’s cached copy. I can see two basic approaches that should work alongside the buffered rendering of the grid (which is obviously essential here).

The key here is getting the first amount brought over and rendered as quickly as possible. If the total number of records is too large to hold in memory then you need to use a buffered store. In this case, however, the only issue with a few thousand records is likely to be transfer and load time. So if you bring over a reasonable amount in one go and add that to the store that should get the ball rolling. Then proceed to read the rest in reasonable sized chunks to avoid large pauses as you decode and add each chunk of records to the store. You can keep the store up to date with the server-side changes like this as well.

This is very similar to what the buffered store will do for you. It will request pages of records from the server. The only limitation is that as-is, a buffered store will not reload pages when they are present in its cache. If you are using a buffered store, the process of keeping it up to date with the server is quite different. It will involve access the page cache which is an internal aspect of the buffered store. But it sounds much closer to what you are trying to accomplish. I would recommend discussing this in the forum and see about getting a feature request created to more directly support this scenario.

If you read the posts above, you will see that other users have extended the reach of the core components to solve their specific use cases even though the component may not support that 100% out of the box. While this does present upgrade challenges, it can not always be avoided. Which is why I recommend opening a feature request as you progress towards solving for your specific use case… That and try to maintain such code in an area you know to check when you upgrade.

In my pre-Sencha life as a user of Ext JS, we maintained any overrides or patches to the framework in a separate location from the main body of our application to help us reconsider those items when we next upgraded. It was also a key advantage that the framework source was provided so that we could always solve our issues even if we had to resort to changing that code (always a last resort of course).

Even if you don’t have to modify the framework code, it is a good idea to read through the sections most relevant to you to better understand what is going on under the covers. In this case, I would look at how the page cache is managed by the store to see how you might be interact with or mimic that functionality.

For specific discussions like this, the forums are the place to go. The thread you mentioned was trying to edit a buffered store and that was not and still is not really supported. A buffered store is best thought of as a very large, partially available result set. In 4.2, the buffered rendering of the grid is independent of the store (buffered or normal), so you can use a normal store and perform edit operations.

I have tried it now with 4.2.0 and it does not work at all. Rows are not added to the grid.
Looks like buffered grid is useless unless all rows are pre-populated during grid creation. Correct?
Try to change buffer-grid.js as in below.
Thanks

var store = Ext.create(‘Ext.data.Store’, {
........
data: [],
//data: createFakeData(5000),
........
});
“store.add(createFakeData(5000))”

http://www.xenophy.com/extjsblog/5075

Provision: Japan Sencha User Group
http://www.meetup.com/Japan-Sencha-User-Group/about/

In 4.1 I got around the issues with store syncing on buffered grid by calling Ext.Ajax.request directly :\

Love the Kitchen Sink demo, the Neptune theme is looking good!

I noticed http://ext.ensible.com/ Calendar is now a part of the demos, but couldn’t look it up in the API. I’m rather curious as to whether Extensible will now be part of Sencha? I haven’t talked to Brian in years it feels.

We may make it the default, but that would potentially break code that assumed things were in the DOM that would now come and go. To your main point - yes, the concerns are now separated and the store can do whatever it needs to do while the view manages its own issues. This was a bit of a challenge for grouping due to collapsed groups but it should be there.

I can appreciate the challenge there - if you need low-level features like that you will need to dig in deeply to the grid internals. Sadly that puts you in a hard way when we improve the component or add some of these missing features on our side. I don’t see a way to avoid such conflicts when making those kinds of deep changes on both sides.

That said, in an ideal world, the component has all the features you need and you don’t need to dig in so deep… it looks like we have addressed many of the needs you listed in 4.2: locked tree-grid and buffered tree rendering (coming in the next refresh). We have experimented with horizontal buffered rendering, but have not had time to settle on and implement a solution. Your suggestion is one of the front-runners by the way.

Thanks.

@Arthur can you give out a roadmap for the grid buffering?  I’ve been making modifications to the NodeStore, TreeStore, Lockable, Store and GridPanel.  There were a significant changes made to get buffered (vertical+horizontal), locked tree grids to get working and I’m getting a bit frustrated each time there’s an upgrade.

Are you guys planning on an X-Y buffering anytime soon?  I think TableChunking will be needed for horizontal buffering—it just needed to be 4 tables at a timet to have overlap in both XY directions.

Yes, this has been in the product since 4.0 - check out http://docs.sencha.com/ext-js/4-1/#!/example/grid/grid-plugins.html

For the common case, a normal (non-buffered) store has all the normal store features: filtering, sorting, grouping. Using the bufferedrenderer plugin, the grid only renders the necessary rows. All grid and store features should work.

The buffered store is still an option for massive data sets. Since these are never expected to be fully loaded by the client, features like filtering, sorting and grouping must be handled by the server. The use of a buffered store automatically activates the bufferedrenderer plugin.

I was told RowExpander-like functionality would be integrated into grids.  Has that happened yet?  If not, any prediction as to when it might?

Does this mean we can now add, remove, sort and filter on the full set of data, not just the rendered/paged data?

@Bharat - I don’t believe the pivot grid has been added yet, at least not in this beta release.

@Jonas Halor - Can you be more specific? I would disagree, but we would love to hear what suggestions you have.

@Alfa1 - Just download the ZIP. Demos are included, but nothing is hosted yet (to my knowledge). It’s still in beta so we may hold off until the stable release.

@fafche and @Bostjan Rihter - I think the engineers are aware, but I’ll mention it. This is the first beta, so we’ll have that working by the full release.