The reason I don't do this is because if the form is in session scope, it hangs around consuming memory until the session goes away.
As a caching mechanism, this bites rocks, because it is cached for each user. :-/ By putting this type of stuff in request scope instead of on the form, it becomes transient regardless of where the form resides. But if you use a DAO layer with caching (like iBATIS), one copy of this stuff can be cached (globally) so you are not hitting the database all the time. Larry >>> [EMAIL PROTECTED] 11/18/03 4:41 PM >>> > From: Mainguy, Mike [mailto:[EMAIL PROTECTED] > Although, I don't really see a major problem with storing the > options in the form itself (just to make things simple). > Anybody have a compelling reason NOT to do this? > i.e. I put my statesCollection as a property on my ActionForm > with a List datatype. Then I can just use the form property to > populate my options. Every time Struts instantiates your Form object, it also creates that list of states. If you have 'state' on more than one form, there's another list, times how ever many users have forms going at any one time. Since the list of states is unlikely to change, I think it makes more sense to put the list in application scope (as a context parameter) and have only one instance of it. However, memory is cheap, so it's probably not going to matter where you put it as long as you're happy with your decision. -- Wendy Smoak Applications Systems Analyst, Sr. Arizona State University, PA, IRM --------------------------------------------------------------------- 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]
