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 considered returning a custom HTTP status code and using either
onError or on5xx (where 5xx is the custom status code for my errors).
I am curious if someone tried this, to know if it was a good choice or
not.

Eric

On Jun 23, 4:24 am, "joe t." <thooke...@gmail.com> wrote:
> 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.
>
> > FWIW,
> > --
> > 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 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.

Reply via email to