PDA

View Full Version : [FIXED][3.0rc1.1] xaction parameter forced by Store execute function



stillema
7 May 2009, 6:47 AM
I realize the xaction parameter is needed to support some of the new features in 3.0, but it's causing problems with my application when it is being forced into my request. This line of code from the Store execute function:


this.proxy.request(action, rs, Ext.apply(options.params || {}, this.baseParams, {xaction: action}), this.reader, this.createCallback(action, rs), this, options);The xaction parameter is being forced in and not allowing me to exclude it without overriding the method.

Condor indicates in this thread that it should be fixed in the latest revision (3910):

http://www.extjs.com/forum/showthread.php?t=67635&highlight=xaction

However, I am working with that revision and that doesn't appear to be the case.

Condor
7 May 2009, 6:49 AM
No, I said the other problems you experienced are solved in SVN, but the xaction parameter is indeed always added, even when doing a legacy 'load' operation.

stillema
7 May 2009, 6:57 AM
Not to sound argumentative, but that's not what you said. Or maybe you can clarify what you meant by "problems" (plural) being solved in the latest revision. What were you suggesting a bug report being filed for?

It seems that the xaction parameter, if it can't be eliminated, should be allowed to be renamed -- as is start,limit, sort, and dir.

Condor
7 May 2009, 7:13 AM
Temporary workaround:

store.proxy.on('beforeload', function(proxy, params, options){
delete params.xaction;
});

But the final solution should probably be that there should be a config option to make store not add an xaction:'load' parameter to the request.

ps. And indeed, the parameter name 'xaction' should also be configurable.

stillema
7 May 2009, 7:21 AM
Thanks -- and that is what I'm ultimately looking for: the option to disable or rename the parameter.

Also, I had my code backwards in regards to the apply/applyIf. That is, it should be apply, because the applyIf is essentially blocking the overrides. I see there is an open thread on this separate issue and I will post there.

christocracy
7 May 2009, 4:39 PM
Ok, I'll have a look into the inclusion of xaction param.

It should only need to be included in certain cases, actually.

- If no DataWriter is installed, it probably doesn't need to be included at all.
- If a DataWriter is installed, then only needs to be included if the Proxy api doesn't have a specific action defined, thus falling back to the Proxy url.

The purpose of xaction is purely for use on the serverside -- it's not used by the Ext code at all. It's simply used for switching in your server-code when multiple Proxy actions pipe into the same url. If all your proxy actions (load, create, save, destroy) are pumped into distinct urls, it's not necessary at all.

christocracy
10 May 2009, 10:41 AM
Ok, xaction is not included when an action has an api-configuration defined for it.

The following proxy configuration will have no xaction parameter sent in Request since each action points to a unique url on server.


var hproxy = new Ext.data.HttpProxy({
prettyUrls: true,
api: {
load: {url: '/users/load', method: 'GET'},
create: '/users/create',
save: '/users/update',
destroy: '/users/destroy'
}
}),


Ext.data.Store#request


if (doRequest !== false) {
// Send request to proxy. The big Ext.apply as 3rd arg here is simply building the request-params
// and applying the xaction parameter.
var params = Ext.apply(options.params || {}, this.baseParams);

// If we have a writer installed and the proxy has no api-action defined, attach xaction to REQUEST
if (this.writer && !this.proxy.isApiAction(action)) {
params.xaction = action;
}
this.proxy.request(action, rs, params, this.reader, this.createCallback(action, rs), this, options);
}