1. #1
    Sencha Premium Member
    Join Date
    Apr 2008
    Posts
    254
    Answers
    2
    Vote Rating
    26
    themightychris will become famous soon enough themightychris will become famous soon enough

      0  

    Default Answered: using config system to instantiate members, classify breaks enumeration

    Answered: using config system to instantiate members, classify breaks enumeration


    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:

    Code:
    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?
    Chief Architect @ Jarv.us Innovations
    Co-captain @ Code for Philly
    Co-founder @ Devnuts - Philadelphia Hackerspace

  2. 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

  3. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    37,347
    Answers
    3542
    Vote Rating
    846
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    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
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

Thread Participants: 1