Adding transaction object to success handler in Ext.form.Action.DirectLoad/Submit?

[Wolfgang]

Would it be possible to provide the transaction object in the submit/load failure handler instead of an empty response object.

When using a simple exception in the backend like


if(!isset($params->id)) {
throw new Exception("Invalid Host Id");
}

the returned transaction object contains the exception text along with the failure type:


{"type":"exception","tid":3,"message":"Invalid Host Id","where":"#0 [internal function]: Hosts->get(Object(stdClass))........................."}

This is bc off the php serverside stack that ships with Ext which is really convenient. In Router.php it sets the transaction object per default like this:


} catch(Exception $e) {
$response = array(
'type' => 'exception',
'tid' => $cdata->tid,
'message' => $e->getMessage(),
'where' => $e->getTraceAsString()
);

However, the transaction is not available in the failure handler on the client side, because of Ext.form.Action.DirectLoad/Submit not passing it through. All they do is to provide an empty response object.

Ext.form.Action.DirectLoad


success : function(response, trans){
if(trans.type == Ext.Direct.exceptions.SERVER){
response = {};
}
Ext.form.Action.DirectLoad.superclass.success.call(this, response);
}

and Ext.form.Action.DirectSubmit


success : function(response, trans){
if(trans.type == Ext.Direct.exceptions.SERVER){
response = {};
}
Ext.form.Action.DirectSubmit.superclass.success.call(this, response);
}


One can use the regular {success=false, errors={}} mechanic, but this change would be a nice addition and make error handling even simpler.
An override would be an option, but it is preferred to stay compatible with the framework.

[kodomo]

But you can manually add the transaction id, or any other data in the server side on the result field, and then the failure handler function can read that data.

Or also, you can generate custom made messages though a event, informing details of the problem.

[Wolfgang]

This is correct. However i would prefer a more "standard" ext built way of doing this, since an exception is, basically, something similar to a failure. It happens just on a more deeper level of the application. And - i like the idea to separate server exceptions from application failures.