Unanswered: Custom proxy to read from another store

Unanswered: Custom proxy to read from another store

Has anyone tried o write a custom proxy which get's it's data from another store?
It would be something like
Store2 <- CustomProxy -> Store1

Store1 would be a store with rest proxy
Store2 would be a subset of Store1 (additional filters, sorters)

This approach, in my opinion would allow an application to have one BIG store, with no filters, that communicates with the backend and a lot of small stores, with different kind of filters and sorters that can be used for different views.

This would solve the problem (which i see a lot of ppl have) of having one store tied to multiple views.
since the core problem they are trying to solve is not to load the same remote data multiple times.

I can think of a couple of other ways to achieve a similar affect. First, you could just clone the store. I don't believe there's a single method to do this but it should be fairly trivial to loop over the records and copy() them all. Another way to do it, similar to the one you've proposed, might be to try to write to a MemoryProxy from the initial store and then use it for all the other stores.

The end results for these 3 techniques aren't all exactly equivalent so I can see arguments in favour of each of them.

This is a first try.
I managed to create a proxy that can read data from another (server) store.
This allows me to have one "master" store that communicates with the server and two other stores that get the data from this store without communication to the server and i can add custom filters on these two stores without affecting the main store.

To each of the stores i attached a grid to see the result.

To have this behavior i needed a special proxy and a special data store ( which only overrides the setProxy function in order to pass a reference to itself )

It would also be interesting to modify the Ext.data.Model (or whichever class is responsible to returning stores when using associations) so that the stores returned are the special kind of stores described above so that we do not end up we a lot of different independent stores when using associations. I think this the desired behavior in 90% of the cases when using associations.

Maybe Ed Spencer can take a look at this thread (since he is responsible for the data package) and think about implementing this idea in future releases.

PS: although the add/update/destroy are implemented they were not tested so they might not work.