We did one app where we had to do this, setup application scope data. We checked for it in the index page, but I didn't like it. With the new Servlet APIs this can be accomplished by setting up a listener for the application startup (I forget what the listener interface is though), which is defined in the web.xml file I believe.
Of course not all containers implement this just yet... Maybe an API could be added to struts to tell some listener that a struts app has started? Say, after the Servlet inits itself or something. - Robert -----Original Message----- From: Schneider, Eric [mailto:[EMAIL PROTECTED]] Sent: Monday, April 22, 2002 1:13 PM To: 'Struts Users Mailing List' Subject: RE: Where is it best to populate default form bean collections et c? I'm curious about this too. How are other developers initializing application scope resources? For example, maybe a list of cities or states. Things that end up in numerous forms that don't change often, but are large enough to be stored in the database. These kind of things don't seem appropriate in a user's session. Thanks, eric. > -----Original Message----- > From: Hoang, Hai [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 22, 2002 1:40 PM > To: 'Struts Users Mailing List' > Subject: RE: Where is it best to populate default form bean > collections > et c? > > > I've been using the Action classes to load the required data > for the form > and place it under session object if the data does change > often and the > dropdown is being used repeatedly. This way, you don't have > to when back to > the database everytime. The draw back to this technique is that the > scalability issue. Just be sure to remove these collections from the > session object when you are done. > > I am very much interest in seeing other techniques being used. > > -----Original Message----- > From: Rick R [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 22, 2002 12:30 PM > To: [EMAIL PROTECTED] > Subject: Where is it best to populate default form bean > collections etc? > > Sorry if I'm not to clear here but I'm really curious about > the best design > principle to use under struts in the following situation... > > Say you want to set up a jsp form and on the form you have > several select > elements. Each set of select elements is created dynamically > from a query to > the database. I have a corresponding form bean that goes with > this page. > > The question I have is it ok to set up the default select > lists inside the > form bean by calls to some other business logic? For example... > > private dogsArray = business.getDogsArray(); > > then your normal set and get method. > > I tend to thin this probably isn't a good idea and it would > be best to have > some action class create the array and then call the > appropriate form bean > set method. I'm not sure though. > > Then what about when the form is reset, I take it you just > make another call > to the default action that sets up your form bean? I noticed > in some of the > examples they have a reset() method inside the form beans > which goes and > sets the fields to default values. This is why I began > questioning the best > practices, since if I follow that route than I really would > have to call > some business logic to populate the String[] arrays for the > select options > in the form beans. > Hopefully I'm making some sense. > > Thanks for any advice. > > Rick > > > -- > 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]> ********************************************************************** This message, including any attachments, contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please contact sender immediately by reply e-mail and destroy all copies. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. TIAA-CREF ********************************************************************** -- 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]>
