I would skeptical about excluding execute. As Wes points out, the framework is designed to bypass validating input initially. After all, it's kind of difficult validating a form you have not yet had the chance to ill out!
On Thu, Jun 11, 2009 at 8:53 AM, Kishan G. Chellap Paandy < kishanchellapaand...@spanservices.com> wrote: > Hi Jim, > > You can exclude methods (in your case execute method) from validation using > workflow interceptor exclude methods parameter. > > <interceptor-ref name="workflow"> > <param name="excludeMethods">execute</param> > </interceptor-ref> > > May be this could help. > > Thank you. > Regards, > Kishan.G > > Team Leader. > www.spansystems.com > > > > -----Original Message----- > From: Jim Collings [mailto:jlistn...@gmail.com] > Sent: Thursday, June 11, 2009 5:54 PM > To: Struts Users Mailing List > Subject: Whats the best way to do validation messages on the same page? > > There's got to be a better way of doing this than the way that I am doing > it. > > Convention plugin. > > According to my projects requirements error/validation/success > messages are supposed to show on the jsp that generated them. So if I > am on a page that adds a record and I leave all the fields blank, > selecting submit will display some errors on that page but will not > move on to a different page. > All of these pages are in the /content dir so if I have: > > some-file.jsp and SomeFileAction.java and if SomeFileAction extends > ActionSupport implements Preparable, then execute() is going to get > called when ever the page is loaded even though it's empty and just > returns "success"... I have to override and annotate execute with > @SkipValidation to prevent messages from being displayed when the user > has first loaded the page. The form on the some-file.jsp calls > some-file!doSomething when the Submit button is selected. This turns > things into a real mess. What the convention plugin does is consistent > but not always predictable. I basically had to break with the > conventions and use a few @Results and an additional action to get > some predictability out of it. > > Anyway... how would you have done this? > > > Jim C. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > >
