I also have a similar method, but I use an Ajax responders to check
the error flag and divert the processing to an alternative function
when it is set.
Since there is no Ajax.Responder for onSuccess, I use onCreate to wrap
the error management code around the provided onSuccess option.
I once
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 22, 2010, at 2:45 AM, T.J. Crowder wrote:
The answer is in the question. :-) If it's a non-HTTP error, it
wouldn't be best practice to use an HTTP error code to represent the
error. (Not that HTTP status codes don't have a fair bit of scope
Oh thank god. i thought i was being incredibly dense using a solution
like that. But having seen no other way to determine the procedural
path to take when the server responds (barring a transport error),
that seems the most effective way to follow one route for successes
and another for
