[fpc-devel] fcl-web webdata example(s) on Windows has some problems

[Michael Van Canneyt]

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 at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>