PDA

View Full Version : Custom generic store then extending for concrete stores



qhas
28 Jun 2012, 5:49 AM
I"m using Ext.4.1.0.

I'm having issues trying to creating a base (abstract like) store, then creating multiple concrete stores based off that.

The code works to inherit from the base (My.ext.data.store.Store), but if I modify the this.proxy.<values> in the constructor of the concrete classes the last one extended will effect the previous concrete classes.

My example:
My.ext.data.store.Store is the generic store.
Admin.store.Roles and Admin.store.Configs are the concrete classes that inherit form My.ext.data.store.Store.
Roles is used first then Configs in the application. The this.proxy.<values> modified in the Configs constructor show up in the Roles object.

Can I do what I'm trying to do in Ext? Should I do it another way?

Thanks,



/**
* I'm trying to create a customized generic store.
*/
Ext.define('My.ext.data.store.Store', {
extend: 'Ext.data.Store',
alias: 'store.mystore',
remoteFilter: true,
remoteSort: true,

proxy: {
type: 'ajax',
url: '/web/model/processor.php',
filterOnLoad: true,
extraParams: {
server: SERVER,
target: null,
action: 'read'
},
reader: {
type: 'json',
root: 'rows',
totalProperty: 'rowcount'
}//eo reader },
/**
*/
constructor:function(config){
this.callParent(arguments);
}
});



I'm then trying to take the generic store and create concrete stores.



Ext.define('Admin.store.Roles',
{
extend: 'My.ext.data.store.Store',
model: 'Admin.model.Role',

constructor: function(){
this.proxy.url = '/web/model/role.php';
this.callParent(arguments); }
});





Ext.define('Admin.store.Configs', {
extend: 'My.ext.data.store.Store',
storeId: 'UserConfigs',
model: 'Aadmin.model.Config',

constructor: function(config){
this.proxy.url = '/web/model/config.php';
this.proxy.extraParams.target= 'App2';
this.callParent(arguments); }
});

burnnat
28 Jun 2012, 8:53 AM
When you specify the proxy object directly on the class body like that, that single object instance will be shared between every instance of the store you create. That's why when you modify the object in one instance, it affects all the others.

What you really want to do is set the proxy config in your constructor - that way, every time the constructor is called, a new independent proxy config object is created. For example:


Ext.define('My.ext.data.store.Store', {
extend: 'Ext.data.Store',
alias: 'store.mystore',

remoteFilter: true,
remoteSort: true,

constructor: function(config) {
config.proxy = this.initProxy();
this.callParent(arguments);
},

initProxy: function() {
return {
type: 'ajax',
url: '/web/model/processor.php',
filterOnLoad: true,
extraParams: {
server: SERVER,
target: null,
action: 'read'
},
reader: {
type: 'json',
root: 'rows',
totalProperty: 'rowcount'
}
};
}
});

Then your concrete stores could look like:


Ext.define('Admin.store.Roles', {
extend: 'My.ext.data.store.Store',
model: 'Admin.model.Role',

initProxy: function() {
return Ext.apply(this.callParent(), {
url: '/web/model/role.php'
});
}
});


Ext.define('Admin.store.Configs', {
extend: 'My.ext.data.store.Store',
storeId: 'UserConfigs',
model: 'Aadmin.model.Config',

initProxy: function() {
var proxy = this.callParent();

proxy.url = '/web/model/config.php';
proxy.extraParams.target = 'App2';

return proxy;
}
});

Using an initProxy() method like this is just one approach. You can build the proxy object however you see fit, as long as it's created in the constructor and not specified directly on the class body.

qhas
28 Jun 2012, 9:23 AM
Thanks, burnnat

That's what I was suspecting with more testing. I don't know if this is a good option going forward, but I'm currently coping the proxy object and set it in the constructor.

This method is working, would you suspect trouble in the future with this approach?




//Base Store class
constructor: function(){
this.proxy = Ext.Object.merge( {}, this.proxy);
this.callParent(arguments);}

burnnat
28 Jun 2012, 9:43 AM
Functionally, I don't see any issue there. I'd just go with whatever you think is the most readable/maintainable. :)

(I'm also wondering why you chose Ext.Object.merge({}, proxy) over Ext.clone(proxy), but again - that's a stylistic/readability thing as they'll both have the same effect in the end.)

qhas
28 Jun 2012, 10:00 AM
Only because I found Ext.Object.merge first. I agree that Ext.clone is more readable, It's changed now.

Thanks again

burnnat
28 Jun 2012, 10:04 AM
You're quite welcome! :) If you feel your question has been answered satisfactorily, you can mark this thread "answered" so it shows up green in the thread list.