> -----Original Message----- > From: Rick Reumann [mailto:[EMAIL PROTECTED] > Sent: Friday, August 13, 2004 1:09 PM > To: Struts Users Mailing List > Subject: Re: Who calls the validate method ??? > > > Leandro Melo wrote: > > > Hi, > > could anyone tell me who calls the validate method of > > the ActionForms? > > I think "you" should:) I find it's often more beneficial to > not rely on > Struts calling this validate() method and instead you should > call this > manually. > > From my other post: > > <snip> - when validation fails and you are back on the > initial form you > will not have access to the previous set request attributes. > It is for > this reason that I now rarely ever set my mapping validate to > "true" and > instead call validate() from my Action after the form submits. The > reason for this is when validation fails > (ActionErrors/Messages return) > I can then call a private setUp() method in my Action that is used to > set up my form with any other request attributes that should > always be > there. > > For example, a common complaint is: "I have a List that I set up in > request scope that is used on the form for the user to select > an item, > but when validation fails this List will not be there." To get around > this problem, simply call validate() manually in your action and if > errors return you can then call a setUp() method that will repopulate > what you need to be in the request, otherwise you just > proceed on as normal.
See, I disagree with this entirely. Pick lists can be put into application scope, if they are small enough. Use the Fast Lane Reader pattern if they aren't. If you need to customize the list based on whatever, then you can that through the list bean ( I wouldn't recommend just putting a list in application scope, rather a bean containing a list to support this kind of setup) and then set the input parameter. If they aren't application in scope, then put them into the session. I know that some people don't like putting things into session/application scopes because of memory.. however memory is not only cheaper then developer time, it's expensable too! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
