Buffered Ext.data.Store issues

[SebTardif]

I think the thread made pretty clear how convoluted the API is.

What have not been covered very well, is that we need a separation between the store and the view. I mean the lazy rendering should be a view concept, I don't understand why it seems most of the APIs end-up in the store.

All lazy rendering settings should be at the view, not at the store. With the current code, I get some weird side effect, like depending of store settings I will get more not visible row renderend or less, and with this, all kind of bugs, including getting half of the visible rows rendered when scrolling.

As long lazy rendering is not the grid default behavior, or a more realistic set of public examples exist, I don't believe we will get something without a large number of issues.

[edspencer]

I believe these are totally separated - what specifically are you referring to where they are too closely coupled?

[stevil]

<snip>

All lazy rendering settings should be at the view, not at the store. With the current code, I get some weird side effect, like depending of store settings I will get more not visible row renderend or less, and with this, all kind of bugs, including getting half of the visible rows rendered when scrolling.

As long lazy rendering is not the grid default behavior, or a more realistic set of public examples exist, I don't believe we will get something without a large number of issues.

I think there are two components to rendering - the rendering of the grid's chrome (panel header, column headers, borders, etc.), and rendering the data - if you're talking about the data, that should be implicitly "lazy", as the grid awaits a data result from the store and the proxy?

Or perhaps I'm missing your point (which is a distinct possibility)?

stevil

[SebTardif]

I'm just talking about the data rendering. Ideally, no code about virtual rendering should exist in the store class. I understand to support infinite scrolling the store need extra code.

I previously listed some strange side effect here: http://www.sencha.com/forum/showthre...ing-AJAX-proxy

At the end of the day, the virtual rendering should not break because of a store state/config.

[stevil]

Is it that the store is doing virtual rendering, or that, in doing buffered prefetches, it's firing off prefetch and/or load events to whatever's listening, in this case presumably the View?

stevil

[edspencer]

The Store is not doing anything to do with rendering. That is all handled in the view layer. If you're aware of code in our framework that breaks that abstraction I'd love to see it

[stevil]

I'm know that *I'm* not - I am interested to know more about what @SebTardif was experiencing...

stevil

[SebTardif]

My last post mentioned a previous thread about the strange side effect on the view via the store. That should be enough to give some pointer.

Beside that, the following use case should also be covered: http://www.sencha.com/forum/showthre...983#post602983

and this one -> http://www.sencha.com/forum/showthre...563#post626563

and also this one -> http://www.sencha.com/forum/showthre...577#post630577