Unanswered: Store, Models, and who is calling Base.initConfig()?

Unanswered: Store, Models, and who is calling Base.initConfig()?

After some problems last friday, I'd dived into the framework code but it leaves unclear. Where and when will this be called?

The actual problem: I had created several custom stores based on the Ext.data.Store. I'm also using the config attribute attaching some extra params. (e.g. applyHost: function(val){this.proxy.extraParams.host=val;}) as a replacement for the old "baseParams"-way (on constructing time only). In one part of the application, everything works (all grids). In another part the does not work. The additional params will not applied, the apply*-methods will not be called (checked). Only if I override the constructor and call after this.callParent(arguments) an explicit this.initConfig() it will works. Currently, I could be possible that the problem occurs when not using grids, but I'm still unsure (will see that next week).

If this is a grid only thing, at which point of object's lifecycle "should" initConfig called? (thinking about a global, custom store component by myself).

Speaking of models and stores, I have a more architectural question: Should proxys defined in stores or in models? Yes, both should work but is there a general recommendation? If we put the proxy, root, and url configurations out of stores direct into the model, than most of the concrete stores will be obsolet. So: "Big" models or "big" stores?

I do not have an answer on initConfig, apart from noting that I observe the same behaviour, whether or not linked with a grid.

Regarding the big store vs big model question, I think the current paradigm in ext 4 is definitely big model, and that it makes sense. The structure of the data retrieved and sent through the proxy is tightly coupled with the structure defined by the model and it seems logical that the proxy should be kept with the model. I think proxies in the store are more for simple store cases where the model is not defined per se and the fields are defined inline in the store. Another way to put it is that though the structure of the data handled by the proxy and the structure of the model can be different, the resulting "usable" data will only ever be that that is defined both in the model and in the data source. Whatever fields are not present in both will not exist for ext. It therefore makes sense to keep the relation between proxy and model "one-to-one". On the other hand the same dataset can be used to build several different stores based on subsets. So one model/proxy for many stores, which also goes in the direction of big model.

It is nice though that this is left open so that other use-cases can be accomodated. So take what I have just said with a pinch of salt, it might be that it's just m,y use cases that call for big model over big store.