Rick, I usually define the setUpForm action URI as the input attribute of the processForm action element. That way if a validation error occurs the request is forwarded to the setUpForm action which repopulates the list and forwards to the page where my list is displayed along with the error message and the users input.
Works for me and I don't have to place anything in the session. robert > -----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]
