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. ;)
On Jun 22, 2:45 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> On Jun 21, 9:58 pm, Jason 'XenoPhage' Frisvold<xenoph...@godshell.com> wrote:
> > 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