Thanks Tim (and Greg) - good to know at least that I'm not missing
something obvious in how I'm doing things.
Tim - I do like the idea of the @HandlesErrors annotation, and the
AjaxErrorInterceptor I think will be an improvement over what I'm
currently doing. A couple of further thoughts:
It strikes me that the common theme here is the content type. It
never makes sense to send back HTML to a client expecting JSON and
vice-versa. I wonder therefore if there would be any value in making
the content type a first class construct, and then it would be
possible to specify the handling on the basis of the content types.
Eg:
@ContentType('text/x-json') public Resolution save() { ... }
@HandlesErrors(contentType='text/x-json') public renderJSONError(...) { ... }
The content type annotation, if present, might automatically set the
right header as well, saving you from specifying it in your resolution
(which is just icing really). The main reason I'd find this useful is
that then I don't need to explicitly maintain the list of events
targeted by the error handler - it will handle anything of
content-type JSON. That in turn means I can move it to a base class
and all I need to do is declare content type on my child class methods
and everything works seamlessly. It's nice in a way also that
declaring the content type becomes useful as documentation too.
Just thoughts - I'd be happy to pitch and help implement something
like this if you think it's a good direction.
Thanks & cheers,
Simon.
On Tue, May 6, 2008 at 8:37 AM, Tim Fennell <[EMAIL PROTECTED]> wrote:
> I've been thinking about the different error handling for different
> methods for a while, but we haven't implemented anything for 1.5.
> Essentially I think I'd like to go to a model where you can decorate
> any method on the class with something like:
> @HandlesErrors public fallback() { ... }
> @HandlesErrors(on="save") handleSaveErrors() { ... }
> etc.
>
> That, I believe would solve your cleanliness issue with
> ValidationErrorHandler - note that this is more or less the last "add
> a method" interface in Stripes, and it does feel out of place.
>
> As for your catching exceptions problem, I believe I can suggest a
> decent solution, which might also generalize nicely for your first
> problem. Let's assume that you use some kind of toolkit or at least
> common set of JS functions on the client, and that you wouldn't mind
> modifying or wrapping it to insert a "special" request parameter so
> that any server-side code can know that any Ajax event is being called
> (possibly as simply as adding _ajax=true to ajax requests).
>
> Then you could write an Interceptor that looked something like this:
> @Intercepts(BindingAndValidation, CustomValidation, EventHandling)
> AjaxErrorInterceptor implements Interceptor {
> Resolution intercept(ExecutionContext ctx) throws Exception {
> boolean ajax = ctx.getActionBeanContext().getRequest()....;
>
> try {
> ctx.proceed();
> if (ajax && !
> ctx.getActionBeanContext().getValidationErrors().isEmpty()) {
> // jsonify error messages and
> // return new resolution
> }
> }
> catch (Exception e) {
> if (ajax) format exception for ajax and return new
> resolution
> else throw e;
> }
> }
> }
>
> The only downside is that from the bean programmer's perspective this
> would be a bit like magic. But it'd be your magic, so maybe that's ok?
>
> -t
>
>
>
> On May 5, 2008, at 6:24 PM, Gregg Bolinger wrote:
>
> > I feel you Simon. Stripes doesn't really do anything special when it
> > comes to ajax. As far as stripes is concerned, a request is just a
> > request and you have to decide what the response is supposed to look
> > like and I'd suspect that most of us format our response a bit
> > differently, even if it is HTML or JSON. So I'd be hard pressed to
> > find
> > a Stripes solve all type of solution.
> >
> > I'll be interested in seeing what the rest of the community might come
> > up with.
> >
> > Gregg
> >
> >
> > Simon wrote:
> >> Hello all,
> >>
> >> I have a common problem that I'd like to be able to solve more
> >> cleanly
> >> than I do. I often have action beans that expose a piece of logic
> >> to
> >> several different types of callers. For example they may support the
> >> same call via AJAX to which they return JSON, and as a regular web
> >> request, to which they return HTML. Typically I will set up a
> >> different method on the action bean to handle each case and they will
> >> both call some shared internal logic to do the operation but return
> >> different resolutions with the results.
> >>
> >> This is easily done except for two things:
> >>
> >> - how to handle errors in validation of input parameters
> >> - how to handle general errors in the execution of my action bean.
> >>
> >> In both cases I want my JSON methods to return JSON formatted errors
> >> and my HTML methods to return HTML pages displaying errors. The
> >> default behavior of Stripes is that my JSON methods all return HTML
> >> errors which, of course, horribly breaks the parser at the other end.
> >>
> >> For the validation case I tried implementing ValidationErrorHandler
> >> on
> >> my action bean. However this has to be done on a whole-bean basis
> >> - I
> >> then have to put inside there some kind of switch logic that
> >> differentiates the HTML cases from the JSON cases. This feels very
> >> unclean. For the general error handler the only solution I've found
> >> is to wrap every method call with an appropriate try / catch block
> >> explicitly and return the appropriate content back from it.
> >>
> >> None of this is very hard, but it has a real "square peg in round
> >> hole" feel to it. Does anybody know of cleaner solutions to handle
> >> this kind of problem? Will Stripes 1.5 offer anything new to help?
> >>
> >> Thanks for any suggestions!
> >>
> >> Simon.
> >>
> >> -------------------------------------------------------------------------
> >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> >> Don't miss this year's exciting event. There's still time to save
> >> $100.
> >> Use priority code J8TL2D2.
> >>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> >> _______________________________________________
> >> Stripes-users mailing list
> >> Stripes-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/stripes-users
> >>
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > Don't miss this year's exciting event. There's still time to save
> > $100.
> > Use priority code J8TL2D2.
> >
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> > _______________________________________________
> > Stripes-users mailing list
> > Stripes-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
