Rick,
I just read your post on this question and wanted to share how I handle this.
Whenever I have a page with a dynamic dropdown list, I set validate to false for the
action that I am submitting to in struts-config.xml.
Then in my action, I call the validate method on the ActionForm that I get.
AddEmployeeForm myForm = (AddEmployeeForm)form;
ActionErrors errors = myForm.validate(mapping, request);
if (errors.empty()) {
//work with the submitted data
} else {
//recreate dynamic lists as collections and put them in the request.
saveErrors(request,errors); // so <html:errors/> can display them
return new ActionForward(mapping.getInput()); //forward back to the
submitting jsp page
}
Jacques
> -----Original Message-----
> From: Rick Reumann [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 11, 2003 10:48 AM
> To: Struts Users Mailing List
> Cc: [EMAIL PROTECTED]
> Subject: Re: still wondering Re: Where to repopulate dynamic lists ?
>
>
> Sorry Craig to e-mail you directly but this topic has been up for a
> while and I'd really be curious on your take on this. (I'm working on
> struts demo and I don't mislead others by doing something 'wrong').
>
> To recap I'm wondering what is the best practice for repopulating a
> dynamic list that a user would need on a form. For example possibly it's
> a form where a user has to select from a list of"Order Numbers"(which
> could frequently change and could be based on the user logged in). The
> way I currently tackle this is in the setUpForm type of action a
> business object is called which returns to me this list and puts the
> list into request scope to be used on the form. The problem is when the
> user submits the form and validation returns false. Somewhere this list
> needs to be repopulated. I could of course put this list (or even the
> form bean) into session scope, but I thought that was to be avoided
> since the only thing this list is used for is this one page. To solve
> this problem I've been calling this business object to get my list in
> the reset() method and putting it back into scope. I've heard others say
> this is a bad idea(although I'm not sure why) and yet I haven't really
> heard any other'much better' solutions.
>
> Some comments below on Mitchell's last post..
>
> On Tue, 11 Feb 2003 10:20:52 -0500
> "Mitchell Morris" <[EMAIL PROTECTED]> wrote:
>
> > > > #1) Create a custom tag library to share an application-wide
> > > > cached value of the order list, and populate the list into scope:
> > [snip]
> > >
> > > This is probably a pretty good solution, although doesn't this go
> > > against the thought of all the objects to display should be set
> > > up before you even reach the JSP page? Basically now your JSP
> > > page is doing business logic.
> >
> > Ooooh ... philosophical purity! I seen some of that once! I'm not
> > entirely sure where the objection lies here, because the view object
> > (JSP) isn't directly manipulating the model object (order list), but
> > rather is intermediated by a controller object (tag library). Seems to
> > me the MVC purity is being maintained. On the other hand, I might be
> > wrong. At least it isn't a scriptlet.
>
> Trust me I'm not against using a tag to do it in the JSP page, I'm just
> wondering how this is any "more pure/better" than just setting the list
> back up in the reset method?
>
> > > One solution I thought might work is every time the list was
> > > updated to
> > > the db I'd make sure to get a new cached copy and put that into
> > > application scope which all the user's cold have. This would
> > > be a great
> > > option except this list could be very specific to a
> > > particular user- it
> > > wouldn't work well in application scope because of this since
> > > the lists
> > > could vary depending on the user logged in.
> >
> > Well, you could certainly go with this scheme even in a user-specific
> > case. The tag library would need to interact with the other model
> > objects in session scope to coordinate the user's identity and thus to
> > extract/cache the correct order list. It's starting to look icky,
> > though, so you might now like choice #2 better.
>
> Yes, very icky I think. Better would be for each user's session to hold
> this list data or repopulate this list (where/when?) before getting
> back to the form upon validation errors.
>
> > > > #2) Have an Action populate the list into the Form before
> > > > forwarding to the display page. The chain starts with your action,
> > > > which can implement your desired caching scheme for the list of
> > > > orders, then displays the JSP. The JSP submits back to an action,
> > > > which
> > > can restart
> > > > the cycle.
> > >
> > > That's currently what I do but the problem I'm running into is when
> > > validation returns false. How/where is the list going to be
> > > repopulated
> > > before it returns back to the jsp form page? The reset method
> > > seems like
> > > the best place but maybe I'm wrong?
>
> <snip>
>
> > This means that I've been wrong all along, and the options collection
> > shouldn't have been in the form at all, but should be in session
> > scope. I'd still have the action->jsp->action chain, but the first
> > action should make sure the correct list object is in session scope
> > instead of putting it into the form.
>
> Yes, actually I never did put the list into the form bean but had
> initially put the list in request scope. Now we've come full circle:)
> We're back to the beginning where it seems the choices seem to come down
> to:
>
> 1) putting the list into session scope (the list will reset when the
> user hits the setUpAction on another request to do this type of action).
>
> or
>
> 2) put the list into request scope and repopulate this list when reset
> is called.
>
>
>
>
> --
> Rick Reumann
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
