Off the top of my head, I can think of a few things.

   - Add a request header -- or use an existing one, like X-Requested-With
   -- to detect these ajax requests and have your
   ActionBeanContext.getSourcePageResolution() behave differently if it is
   present.
   - Add an interceptor that detects when you will be doing validation
   manually (possibly using the aforementioned request header) and bypass the
   BindingAndValidation lifecycle stage altogether.
   - Leave things like they are now, and add a @ValidationMethod in your
   ActionBean that calls getContext().getValidationErrors.clear() when
   necessary. It is !getContext().getValidationErrors().isEmpty() that triggers
   the forward to the source page.

Just some thoughts. I'm sure there are more ways to handle it.

-Ben

On Sun, Feb 1, 2009 at 6:27 PM, Chris Cheshire <[email protected]>wrote:

> (I have searched through the archives, and can't quite find what I
> want, although this is probably very similar to everything that has
> already been discussed).
>
> I have a number of forms on my site that are built on the fly using
> javascript and then submitted by ajax. The actions all send back a
> JSON representation of an object containing information about the
> success/failure of said actions. Any errors are represented as an
> array of strings, which are then inserted into the DOM at the
> appropriate spot using javascript. I am building the errors using the
> stripes error localization :
>
> new LocalizableMessage("my.error.key").getMessage(locale)
>
> I have no @Validate annotations on fields and no @ValidationMethod
> annotations on methods - I do any validation inside the action handler
> methods and build the errors manually.
>
> I am seeing a bajillion of these in my error logs :
>
> 2009-02-01 10:57:46,972 [http-80-17] ERROR
> net.sourceforge.stripes.action.ValidationErrorReportResolution
> Class : net.sourceforge.stripes.util.Log
> Line : 78
>
> java.lang.IllegalStateException: Here's how it is. Someone (quite
> possibly the Stripes Dispatcher) needed to get the source page
> resolution. But no source page was supplied in the request, and unless
> you override ActionBeanContext.getSourcePageResolution() you're going
> to need that value. When you use a <stripes:form> tag a hidden field
> called '_sourcePage' is included. If you write your own forms or links
> that could generate validation errors, you must include a value  for
> this parameter. This can be done by calling request.getServletPath().
>        at
> net.sourceforge.stripes.action.ValidationErrorReportResolution.execute(ActionBeanContext.java:277)
> [stripes.trunk.jar:1014M]
>
> and then a ton of trace info going back into stripes dispatcher and
> then tomcat - but it never contains any information about what action
> and handler actually caused this. The thing is, there is no sourcepage
> - it is an ajax action that does not redraw a page afterwards. I can't
> override getSourcePageResolution() in my context subclass, because I
> have other non-ajax actions that do need it.
>
> I just want these errors to stop. My ajax action handlers are working
> just fine, throwing the errors that they should, when they should and
> generally working from a usability standpoint....except for these
> stripes errors.
>
> I saw a comment in the archives about validation errors being
> generated from typecast errors, but that doesn't matter to me. I want
> it to ignore such things and stick with the default value, and then my
> custom data validation can decide whether something was entered or
> not. I can't change everything to a string, because I am using beans
> for some of the form properties and this would created a huge
> nightmare.
>
> How do I suppress these errors, or better yet, guard my code so that
> they don't occur, given how my actions work?
>
> Thanks
>
> Chris
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Stripes-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users

Reply via email to