On Wed, 18 Aug 2010, ABorka wrote:
...snip...
ExtJS however, will only have 'remote' type if the server response is
proper for it (having a root /which is "rows"/ in our case), all other cases
instead of 'remote' it has the type 'response', regardless of our "success"
property being true or false.
Unfortunately, the ExtJS documentation is rather terse where this is
concerned.
So, if "rows" is not supplied, type='response' and the 'success' property
must simply be checked ? Or do you suggest adding "rows" to the error
response ?
I'm not sure if this is also the case if you are using a DirectStore ?
The docs for Ext.DataProxy -> events -> exception says it in more detail.
"
Fires if an exception occurs in the Proxy during a remote request. This event
is relayed through a corresponding Ext.data.Store.exception, so any Store
instance may observe this event.
...
# type : String
The value of this parameter will be either 'response' or 'remote'.
* 'response' :
An invalid response from the server was returned: either 404, 500 or
the response meta-data does not match that defined in the DataReader (e.g.:
root, idProperty, successProperty).
* 'remote' :
A valid response was returned from the server having successProperty
=== false. This response might contain an error-message sent from the server.
For example, the user may have failed authentication/authorization or a
database validation error occurred.
"
We are always getting type='response' now (due to "response meta-data does
not match that defined in the DataReader") with the "rows" not being there
when an exception/error happens server side, so no error message we pass is
processed in our ExtJS.
I do not know about DirectStore, I just started with ExtJS/JSON with playing
with the demo apps from fcl-web a few days ago :)
Does it hurt anything if we just append a "rows":"" to our error/exception
replies? I did that with the 1st demo app and it works so far, displays the
errors from the server side now (like "DB field X cannot be null", "Cannot
connect to DB server", "Invalid DB user", etc.).
I don't 100% agree: the exception() handler must also be able to handle
'response'.
If there is a server crash or so (which will result in a 500 error code) ,
it must also be able to handle that.
We can add the "rows" for convenience, but nevertheless the error handler
must also handle the 'response' case.
Michael.
AB
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
