Personally, I like to keep my ActionForms as dumb as possible (I actually use DynaValidatorActionForms). I see them as simple data transport mechanism. When ever I have to prepopulate the ActionForm for a "prepare" type of Action I do it within a the Action class (not explicitely - I delegate to a service layer to handle this).
For me, this keeps things separate, simple and cohesive. robert > -----Original Message----- > From: Phase Web and Multimedia [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 14, 2003 10:12 AM > To: Struts Users Mailing List > Subject: RE:Collection Population Post-Validation Best Practice > > > Greetings again, > > I appreciate the afformentioned approaches (Robert, Karim, Puneet). I find > Roberts to be the most logical, simple and clean for myself. I use > LookupDispatchAction so this would actually be easy to do. I was > getting the > loop for the very reason you mentioned :-D. It was a test app to > see how to > address the problem of populating collections post validation and I was > calling the process Action. > > So the practice would be to separate the entry Action from the process > Action. Use the entry action as your input for errors and it will have the > logic to populate your collections prior to showing the page. > > It also seems to me that the ActionForm does not exclude us from making > calls to our business logic from within the validate method. So if I have > any standard prepopulation (post validation)... I can just call my logic > classes and set the appropriate members of the ActionForm from within the > validate prior to the ActionErrors returning to the input page. > > Something like (with validator): > > public MyActionForm extends ValidatorActionForm { > > ... > > public void setMyCollection(ArrayList myCollection) { > > this.myCollection = myCollection; > > } > > ... > > public ActionErrors validate( > ActionMapping mapping, > HttpServletRequest request) > { > > // run my validator validation and capture error > ActionErrors errors = super.validate(mapping,request); > > // run my own validation > if (x != 5) { > > errors.add("myErrorMessage", > new ActionError("my.custom.error")); > > } > > if (errors.empty()) > { > return null; > } else { > ... > // populate ActionForm collections here and return errors > this.myCollection = MyLogicClass.getMyCollection(); > //retrieves Collection > > return errors; > } > > > } > > } > > So then here is the final question: > Is it appropriate practice to have logic classes being called in the > validate method to populate collections in the form? What's the official > position? > > Thanks, > Brandon Goodin > Phase Web and Multimedia > P (406) 862-2245 > F (406) 862-0354 > [EMAIL PROTECTED] > http://www.phase.ws > > > -----Original Message----- > From: Karim Saloojee [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 14, 2003 5:41 AM > To: Struts Users Mailing List > Subject: Re: [Our Practice]Collection Population Post-Validation Best > Practice > > > Hi > > What we have done is introduce a ListManager class. This is a singleton > object that is accessible from the form via its superclass (our custom > superclass). > > What we have done in our form is have two fields for a > collection, i.e. our > dropdown list. The first field is used to populate the values of the list > and the second is used to store the selected value. > > E.G.: > public Collection getListOfPeople() { > return ListManager.getInstance().getPeople(); > } > > public String getSelectedPerson() { > return selectedPerson; > } > > public void setSelectedPerson(String selectedPerson) { > this.selectedPerson = selectedPerson; > } > > Our JSP is coded so that the setup of the dropdown calls getListOfPeople() > and the selected item populates setSelectedPerson(). The taglib > allows this > Struts 1.1 b2. > > This allows us to store the forms in the request and never have to worry > about pre-populating them, this seems to work very well for us. > > I would appreciate feedback wrt this approach. > > Regards, > Karim > > > > ----- Original Message ----- > From: "Puneet Agarwal" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Tuesday, January 14, 2003 1:41 PM > Subject: Re: [Our Practice]Collection Population Post-Validation Best > Practice > > > > Even we had a similar problem in our application: > > > > Agree that making the ActionForm scope to be "session" may > cause problems, > > but storing the information in request scope and copying all that > > information in html and then sending it back to the server > again may cause > > extra network traffic. > > > > We adopted following workaround for this. > > > > 1. Make most of the ActionForm scope as "session", and write a cleaning > > mechanism which could keep cleaning up the HTTP session on some basis. > > What we adopted was "as soon as the user shall operate on the top drop > > down menu of the application, it shall remove any ActionForms more than > last > > 5.(This "5" was configurable). This keeps the HTTP session lighter. > > > > 2. For the screens that have ActionForm scope defined as "request", some > > information was stored in HTML hidden variables but there was special > > mechanism for collection objects. For every such screen one object was > > stored in HTTP session and this object stored all collection objects. > > > > Hope you too find this solution good for your application. > > > > Regards > > Puneet > > > > ----- Original Message ----- > > From: "Phase Web and Multimedia" <[EMAIL PROTECTED]> > > To: "Struts User List" <[EMAIL PROTECTED]> > > Sent: Tuesday, January 14, 2003 12:31 AM > > Subject: Collection Population Post-Validation Best Practice > > > > > > > In the past I have not done any validation in my ActionForm so I have > > never > > > ran across this problem. I read a post from a while back > regarding this > > but > > > the feedback was fairly obscure. I also read in "Struts In Action" > > regarding > > > this problem. But, the solutions were a little vague. So, I am looking > for > > > some creative specificity. > > > > > > Problem: > > > > > > I prepopulate some collections in an ActionForm through an > Action class > > > before I display the jsp form. I use the collections that I > populate in > > the > > > form to create the drop down (<html:options collection="foo">). Upon > > > submittal of the jsp form and a failed validate in my ActionForm i > return > > > back to the jsp page and my collections are not available/null (of > course) > > > because my form is set in request scope. Following are a few possible > > > solutions ,that came to mind, for re-populating my > collections prior to > > > being sent back to ActionMapping's input. I am just wondering which is > the > > > best or if there are some better solutions. > > > > > > 1) Specify the form as a session scope - I don't really want > to do this > > > because I am concerned that as the usage volume goes up I am > potenially > > > going to be passing around large complex objects in the session. I > prefer > > to > > > keep it in the request. > > > > > > 2) Call my logic classes that populate the collections set the values > > > (setXXX(), getXXX())from within the validate method prior to returning > the > > > ActionErrors. - I am not sure how this would work using > Validator. Can I > > > override validate when extending ValidatorActionForm and call > super() to > > > make sure that the Validator validation is called and then > run my logic > > > classes to repopulate the form? > > > > > > 3) Set my ActionMapping's input to go to the Action url > rather than the > > jsp > > > (This was a suggestion in "Struts In Action") - I tried this but I get > > some > > > looping and ultimately a StackOverflowError. See Following: > > > > > > java.lang.StackOverflowError > > > at java.util.HashMap.hash(HashMap.java:257) > > > at java.util.HashMap.removeEntryForKey(HashMap.java:518) > > > at java.util.HashMap.remove(HashMap.java:507) > > > at > > > > > > org.apache.catalina.core.ApplicationHttpRequest.removeAttribute(Ap > plicationH > > > ttpRequest.java:231) > > > ... > > > at > > > > > > javax.servlet.ServletRequestWrapper.removeAttribute(ServletRequest > Wrapper.ja > > > va:340) > > > at > > > > > > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationD > ispatcher. > > > java:676) > > > at > > > > > > org.apache.catalina.core.ApplicationDispatcher.doForward(Applicati > onDispatch > > > er.java:431) > > > at > > > > > > org.apache.catalina.core.ApplicationDispatcher.forward(Application > Dispatcher > > > .java:355) > > > at > > > > > > org.apache.struts.action.RequestProcessor.doForward(RequestProcess > or.java:10 > > > 33) > > > at > > > > > > org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesReque > stProcesso > > > r.java:269) > > > at > > > > > > org.apache.struts.action.RequestProcessor.internalModuleRelativeFo > rward(Requ > > > estProcessor.java:980) > > > at > > > > > > org.apache.struts.tiles.TilesRequestProcessor.internalModuleRelati > veForward( > > > TilesRequestProcessor.java:336) > > > at > > > > > > org.apache.struts.action.RequestProcessor.processValidate(RequestP > rocessor.j > > > ava:950) > > > at > > > > > > org.apache.struts.action.RequestProcessor.process(RequestProcessor > .java:255) > > > > at > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1422) > > > at > org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:523) > > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) > > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > > > ... > > > at > > > > > > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationD > ispatcher. > > > java:683) > > > at > > > > > > org.apache.catalina.core.ApplicationDispatcher.doForward(Applicati > onDispatch > > > er.java:431) > > > at > > > > > > org.apache.catalina.core.ApplicationDispatcher.forward(Application > Dispatcher > > > .java:355) > > > at > > > > > > org.apache.struts.action.RequestProcessor.doForward(RequestProcess > or.java:10 > > > 33) > > > at > > > > > > org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesReque > stProcesso > > > r.java:269) > > > at > > > > > > org.apache.struts.action.RequestProcessor.internalModuleRelativeFo > rward(Requ > > > estProcessor.java:980) > > > at > > > > > > org.apache.struts.tiles.TilesRequestProcessor.internalModuleRelati > veForward( > > > TilesRequestProcessor.java:336) > > > > > > 4) Make sure I have an html representation of the collection > in a form - > > > This idea just seems preposterous. > > > > > > Thanks ahead of time for the info. > > > > > > Brandon Goodin > > > Phase Web and Multimedia > > > P (406) 862-2245 > > > F (406) 862-0354 > > > [EMAIL PROTECTED] > > > http://www.phase.ws > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
