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
