Ohh, I kind of like that @ContentType idea. It could be implemented as
easily as the @HttpCache but I wonder if the idea panned out it might be
better to have something like @HttpHeader that handled both? I don't
want there to be so many annotations I end up with something like this:
@ContentType
@HttpCache
@HandlesEvent
@DontValidate
public Resolution....
That is over doing it a bit. :)
Gregg
Simon wrote:
> 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
>
-------------------------------------------------------------------------
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
