1. #1
    Sencha Premium Member
    Join Date
    Mar 2008
    Posts
    2
    Vote Rating
    0
    boesch is on a distinguished road

      0  

    Default resolving of api methods different in 4.1.3 and 4.2.x

    resolving of api methods different in 4.1.3 and 4.2.x


    I have implemented an application that creates a dynamic ext.direct api for different user groups.
    If the user logs in to the application the api is build via php on the server side.
    Different users get different dynamic api's based on their rights to read, create, update, destroy data.
    The model definition is the same for all users, example:

    Code:
    Ext.define('Ibd.model.Config', {
        extend: 'Ext.data.Model',
    	fields: [
    		{name:'id', type: 'int'},
    		{name:'key', type: 'string'},
    		{name:'value', type: 'string'}
    	],	
    	idProperty : 'id',
    	proxy: {
            type: 'direct',
    		extraParams: {
    			task: 'ALL'
    		},
    		api: {
    			
    			create: Config.createRecord,			
    			read: Config.dispatch,			
    			update: Config.updateRecord,			
    			destroy: Config.destroyRecord
    		},
    		reader: {
    			root: 'results',
    			totalProperty: 'total',
    			successProperty: 'success'
            	}
    	}
    });

    In their dynamic api some users will not get the rights to "create" and "destroy" a record. So their individual api does not list this methods. Everything works fine up to ExtJs 4.1.3. The users can read and update data and cannot create and destroy data. The api-methods are evaluated at runtime, when the user tries to create or destroy a record.

    In ExtJs 4.2.X the evaluation of the proxy api definitions seem to be handled earlier, because my form won't load with the error message:
    " Ext.data.proxy.Direct.resolveMethods(): Cannot resolve Direct api create method undefined"

    I would say:
    "Yes, that's right the create method is not defined in the api because the user has no right to create a record, but so what, the user hasn't tried yet to create a record".

    Is there a possibility to get the 4.1.3 evaluation behaviour of Ext.direct in the 4.2.X releases?
    Or do i have to catch the error by hand and handle it, and how do i do it?
    Or are their other suggestions for implementing a dynamic api based on user rights?

    Thank you very much
    Andreas

  2. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    37,646
    Vote Rating
    899
    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


    So is it that the Ext.Error.raise('Cannot resolve directFn ' + fn); executes that you would like to skip?
    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.

  3. #3
    Sencha Premium Member
    Join Date
    Mar 2008
    Posts
    2
    Vote Rating
    0
    boesch is on a distinguished road

      0  

    Default


    Yes. I use this solution at the moment:

    Code:
    Ext.Error.handle = function(err) {
        if (err.sourceMethod == 'resolveMethods') {
            // maybe log something to the application here if applicable        
            return true;
        }
        // any non-true return value (including none) will cause the error to be thrown
    }

  4. #4
    Sencha - Ext JS Dev Team
    Join Date
    Jun 2011
    Location
    San Diego, CA
    Posts
    226
    Vote Rating
    43
    nohuhu has a spectacular aura about nohuhu has a spectacular aura about nohuhu has a spectacular aura about

      0  

    Default


    That error is there for a reason: when Ext.Direct method cannot be resolved, most of the time that means that there is an error in the application code. Instead of removing the error message, I would suggest to stub out the methods in question, something like that:

    PHP Code:
    (function() {
        var 
    stubFn = function() {
            
    Ext.Error.raise('This should not have happened!');
        };

        
    Config = {
            
    createRecordstubFn,
            
    dispatchstubFn,
            
    updateRecordstubFn,
            
    destroyRecordstubFn
        
    };
    })(); 
    When Ext.Direct provider is initialized, it will overwrite these stub functions with real ones. However if any of these gets called without being properly initialized by Ext.direct.RemotingProvider, you will get a nice exception helping you to pinpoint the problem.

    Regards,
    Alex.

Thread Participants: 2

Tags for this Thread