using config system to instantiate members, classify breaks enumeration

[themightychris]

Coming from a couple Sencha Touch 2 apps, I thought this would be a nice way to use the config system to start my API interface:

Ext.define('MyApp.API', {
    mixins: {
        observable: 'Ext.util.Observable'
    }
	,singleton: true
	,requires: [
		'Ext.direct.Manager'
	]
	
	,config: {
		provider: {
			type: 'remoting'
			,url: '/api/router'
			,namespace: 'MyApp.API'
			,actions: {
				userService: [{
					name: 'getUsers'
					,len: 0
				}]
			}
		}
	}
	
	,constructor: function(config) {
		this.initConfig(config);
		this.mixins.observable.constructor.call(this, config);
	}
	
	,applyProvider: function(provider) {
		// transform provider config into instantiated provider while registering it with the Ext.Direct manager
		return Ext.direct.Manager.addProvider(provider);
	}

	,updateProvider: function(provider, oldProvider) {
		if(oldProvider)
		{
			Ext.direct.Manager.removeProvider(oldProvider);
		}
	}
});

However, ExtJS 4.1's initConfig crawls all over my objects and transforms them with Ext.Object.classify. The "actions" literal object within my config value gets transformed too, and when the provider constructor tries to use a for..in...hasOwnProperty loop to enumerate the keys in actions nothing comes up because classify moved them to the prototype.

What is the need for classify? Should the provider code be patched to deal with classify-d objects? Should classify not be applied deeply? Or is it just hopeless to use the config system in ExtJS4.1 like it is used in ST2?

[mitchellsimoens]

To be totally honest, I'd stay away from the config object in Ext JS... it wasn't fully worked out like it has been in ST2. I use it for some utility classes but that's really just because I want to use the simple getters/setters