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(ApplicationH
> > ttpRequest.java:231)
> > ...
> > at
> >
>
javax.servlet.ServletRequestWrapper.removeAttribute(ServletRequestWrapper.ja
> > va:340)
> > at
> >
>
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.
> > java:676)
> > at
> >
>
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatch
> > er.java:431)
> > at
> >
>
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher
> > .java:355)
> > at
> >
>
org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:10
> > 33)
> > at
> >
>
org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcesso
> > r.java:269)
> > at
> >
>
org.apache.struts.action.RequestProcessor.internalModuleRelativeForward(Requ
> > estProcessor.java:980)
> > at
> >
>
org.apache.struts.tiles.TilesRequestProcessor.internalModuleRelativeForward(
> > TilesRequestProcessor.java:336)
> > at
> >
>
org.apache.struts.action.RequestProcessor.processValidate(RequestProcessor.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(ApplicationDispatcher.
> > java:683)
> > at
> >
>
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatch
> > er.java:431)
> > at
> >
>
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher
> > .java:355)
> > at
> >
>
org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:10
> > 33)
> > at
> >
>
org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcesso
> > r.java:269)
> > at
> >
>
org.apache.struts.action.RequestProcessor.internalModuleRelativeForward(Requ
> > estProcessor.java:980)
> > at
> >
>
org.apache.struts.tiles.TilesRequestProcessor.internalModuleRelativeForward(
> > 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]>