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(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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
