What? You're going over my head? Fine. Be that way. I'm now going to charge you double for my free advice and unsolicited opinion :)
[snip-and-rearrange] > 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. Now I'm confused ... if you don't have the property in the form, then what kind of "reset()" are we talking about? If you're suggesting having "ActionForm.reset()" do anything besides release its own resources, then I'm agin' it. My sneakiest suggestion was to presume that there will continue to be only one instance of your form bean instantiated and you could get away with not releasing the list reference in the reset() method so it would still be there when the form validation failed. If your objection is having the reference in the session scope after the action chain is finished, then have action #2 remove it [via pageContext.removeAttribute()]. If other people have objections, then let them stand up and state them. [snip-and-rearrange] > 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. I'll go out on a limb and say there aren't any "a-Ha!" solutions of staggering brilliance and philosophical purity. If there were, then somebody else would have already written about them (Hi, Ted!) I'll throw out my guidelines: (1) hidden fields are evil, and allow those bastard users to screw me over (2) things for this user belong in session scope (3) things for all users belong in application scope (4) the machinery (Struts et al.) uses whichever scope it likes (often request) #1 means I hardly ever think putting things in request scope is a good idea. I'm certainly not going to trust whatever comes back once the user touches it, so if I need to know it later then I'd better save it where the user can't touch it. That means that I keep all manner of things in session scope, like the aforementioned order list as well as all the model objects. Global object caches and their ilk live in application scope because database calls are too damned expensive to make unless it's really really necessary. paranoia-is-its-own-reward-ly y'rs, +Mitchell --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
