it is a long time ago since i decided to discuss this:
It is common task to me to deal with grids configured with an Ajax proxy and a JSON reader receiving JSON-encoded data coming from a php back-end.
So far, so good.
The boring thing is coming when you have to deal with the exceptions which may occure.
If you have a "true" exception, then you could easily use the 'exception' handler of the proxy object to work with it (for example, to show an error message or so on).
But what is a "true" exception in fact - i have experimented with the following situations:
1. Within the php script i included as first line 'sleep(35)' (because the default proxy timeout is 30)
In this case, Ext fires the "exception" handler after 30 secs.
2. I completely stopped Apache on the backend:
In this case, Ext fires the "exception" handler almost immediately (after 1 second on a machine running raspbian and after ~ 8 seconds on a Windows machine running Xampp. Why is this difference - is a separate question).
And here is the first problem (not so critical):
In the proxy's "exception" handler i'm unable to tell the user why the exception occured - due to a server timeout or due to the fact that the server is not reachable at all. No chance for this because the network request does not contain any response headers/data
Unfortunately, there is a third possible situation, also:
3. The php script may contain some kind of a typo or simply a php warning/error may occur (this is quite unpredictable when you have complicated scripts on the server). As a result - you end up with some response text which is not properly JSON encoded or even is empty (for example, if you issue a "die()" command on the first row of the script).
And now comes the second, and more-boring problem:
In this case, the "exception" handler of the proxy is NOT fired.
And to be honest - this is a normal behavior, because the web server returns in fact entirely valid response headers and response text, something like this:
Code:
<br />
<b>Fatal error</b>: Call to undefined function UNDEFINED_PHP_FUNCTION() in <b>/var/www/scripts/grid/php/dumpData.php</b> on line <b>9</b><br />
UNDEFINED_PHP_FUNCTION() of course is a fictional php function.
Of course, Ext does not need to know if this is a "true" error, but in fact - it is an error and i need a way to deal with it.
Obviously - this will be not possible via the "exception" handler of the proxy, because the event is not fired at all.
So - i need a separate place to check if this response is valid or not - for example, it could be considered invalid if the text received is not valid JSON.
Unfortunately, this must be accomplished somewhere outside the proxy event handlers (which are only metachange and exception).
And i want to ask you - where?
Initially - i considered to try with the "exception" event of the proxy's JSON reader, which, according to the docs, will fire when "the reader receives improperly encoded data from the server".
However, the event does not fire in the above situation (my hope was that "improperly encoded data" means "invalid JSON" for the JSON reader, but that is not true and it will be good the API docs to clarify this).
And now - i'm hesitating where to include the additional control code for the response text.
What could you suggest, guys?
All this leads me to a separate proposal:
Do you think it will make a reason if an additional event handler could be added to the Ext.data.proxy.Ajax object - something like "datareceived", for example?
Such an event could allow us to deal with the response directly within the Proxy object. Now it is only possible if an exception or metachange occurs.
Excuse me if this sounds meaningful, but personally for me - the presence of such an event will make the task of validating the response data much more useful, because it will be made on a single place.
Now i must deal with exceptions within the Proxy and with the invalid JSONs somewhere else (not sure exactly where?)
Proposition regarding Ext.data.proxy.Ajax events
Aucun commentaire:
Enregistrer un commentaire