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 failures/errors. Would be interested in seeing some
tips for that wrapper magic. ;)
-joe t.

On Jun 22, 2:45 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> Hi,
> On Jun 21, 9:58 pm, Jason 'XenoPhage' Frisvold<xenoph...@godshell.com> wrote:
> [snip]
> > What about a non-HTTP error?  What if, for
> > instance, myId was invalid?  What is the proper way to pass that
> > information back to the ajax application?  Is it ok to use a custom 4xx
> > error?  Or should I be using JSON or XML to handle this?
> 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
> creep in them already.)
> I've standardized by having *all* of my Ajax calls return data in the
> same way. They all return JSON-formatted data, and the format for
> success is always:
>     {
>         "success": true,
>         "otherdata": "here"
>     }
> and the format for errors is always:
>     {
>         "success": false,
>         "errMessage": "error message here"
>     }
> In any given application, I tend to have a  wrapper around Prototype's
> ajax stuff with some problem-domain logic in it. That wrapper always
> checks for the `success` flag on calls and routes to the error handler
> if it's not there.
> --
> T.J. Crowder
> Independent Software Consultant
> tj / crowder software / comwww.crowdersoftware.com

You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to