Dynamic Proxy URLs

[stephenr85]

With a REST proxy, rather than only allowing us to append a respective model ID, I would have expected to be able to define multiple variables in the URL. This is also sometimes necessary for standard AJAX URLs. I created a proxy override that uses a template to generate the URL. I'm using a standard Ext.Template, because it seemed an Ext.XTemplate seemed like overkill; although, the code could easily be modified to accomodate that.

I'm posting the snippet here for anyone interested in doing the same thing. Any ideas for improvement are more than welcome.

Ext.define('MyNamespace.data.proxy.Ajax', {
    override: 'Ext.data.proxy.Ajax',
    buildUrl: function(request){
        //Create a template with the URL and replace the variables
        var url = this.getUrl(request),
            urlTemplate = new Ext.Template(url),
            params = request.getParams(),
            newUrl = urlTemplate.apply(params);
        //Remove variables embedded into URL
        Ext.Object.each(params, function(key, value){
            var regex = new RegExp('{'+key+'.*?}');
            if(regex.test(url)){
                delete params[key];
            }
        });
        request.setUrl(newUrl);
        this.callParent([request]);
    }
});

Now you could have a url like "/service/model/{id}/update"; and call store.getProxy().setExtraParam('id', 1);

Additionally, you could do something like "/service/model/{id}/{method}" and call store.getProxy().setExtraParams({id: 1, method: 'update'});

[mitchellsimoens]

For REST, why append the method? This should really be resolved by your server with what kind of request method it is... POST, PUT, GET, DESTROY which you can use the actionMethods config to change these.

[stephenr85]

It was a quick ad-hoc example, but you're right. We are using the request methods in our web service. To use a better example, we frequently have issues with URLs like /customer/{ID}/orders, because the "CustomerOrders" store uses the "OrderDetail" model, so using the "append ID" option doesn't work, because we don't want the order ID in the URL. We were reworking some URLs to be more like /customer/orders/{CUSTID}, but this proved to not be an intuitive URL is some cases. Additionally, some of our URLs are moving targets while the service is in development, and I'd much rather maintain the URL on the store config, rather than multiple places throughout that app that are utilizing the store.