paul-- i don't know what version of struts you're running, but if you're running one of the later nightly builds (i don't know when exactly this feature became available), you have access to the ActionMessages class, which ActionErrors now extends. so you comment: "html:errors/ActionErrors would be better off abstracted to a generic 'messages' mechanism" is actually a reality. david winterfeldt posted a sample earlier this week of how to embed html inside the messages tag to avoid forcing html tags into the application resources file.
see: http://www.mail-archive.com/struts-user@jakarta.apache.org/msg16521.html <ul> <html:messages id="message" property="firstName"> <li><bean:write name="message"/></li> </html:messages> </ul> happy coding... Paul Dillon wrote: > Heres my 2 cents on the whole validation thing. It's bit of ramble, so > please don't hesitate to skip over it. :) > > I find the validation mechanism too restrictive. I do my business-level > validation beyond the web-tier, so while I do use ActionErrors for > ActionForm level validation, I have to build additional stuff to present by > business-level validation errors as well. For example: > > I have a CustomerActionForm, with birthDay, birthMonth, and birthYear string > properties. > > I have a generic CustomerDetail bean with a birthDate property of type > Calendar. (This bean gets passed to my Customer entity class to create a > new customer). > > If the user enters an illegal date (eg. 31/2/2001), I pick it up in the > struts validation. If the date is in the future, I pick it up in my > CustomerDetail validation method. > > It would be nice if struts had an Errors class that had a method like: > import(Collection errors, String msgKeyProperty, String > msgValue0Property...). That way I could use one mechanism to render all of > my validation errors, without having my business-type errors tied to any of > the struts classes. > > Oh and one more thing: after a successful form submission, I immediately > forward to the next screen in the workflow, with the success message > inserted at the top. This saves having to go to an intermediate success > page. So for me at least, html:errors/ActionErrors would be better off > abstracted to a generic "messages" mechanism. > > And lastly... having to stick <li> tags in my error-messages file seems > rather messy. Am I doing something wrong here? > > Thanks for listening :) > > Paul > > ----- Original Message ----- > From: "Antony" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, October 18, 2001 5:17 PM > Subject: Re: where should validation happen? > > > > > Nice discussion. > > I like validate() method because it can give access to ActionError > objects, > > so one can > > easily produce internationalized error messages and forward back to input > > page, and IMHO > > that`s a useful feature. Just my 2 cents anyway;-) > > > > ----- Original Message ----- > > From: "Robert Parker" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, October 18, 2001 12:35 PM > > Subject: Re: where should validation happen? > > > > > > > >From my experience there are some subtle details when using the > > validate() > > > method of the form bean... > > > The validate method is called unless you set the validate attribute in > the > > > struts config to false. > > > If an error is found by your validate method, struts seems to delegate > > back > > > to the input (jsp) as specified in the config, hence your action > handlers > > > perform method is not called. > > > My preference is to perform basic field/type validation in the browser > > using > > > javascript, and business type validation I handle via beans called from > my > > > action handler class. > > > Letting struts call the validate() method for me has given me problems - > > as > > > I often have my action handlers populate say collections of lookup > values > > > for selection lists etc. Hence if struts does not call my perform > method, > > my > > > selection lists will be empty. Note I discovered this after I had > designed > > > my action handlers this way... > > > regards > > > Rob > > > > > >
