I generally use a "static initializer" (also called an anonymous block) for
this stuff.
For example state codes could be done in a static class called States.java
public static class States {
private HashMap statesMap;
public HashMap getStates() {
return this.statesMap
}
public void setStates(HashMap states)
{
this.statesMap = states;
}
// Begin anonymous block for initialization
{
this.setStates(this.initializeStates());
}
private HashMap .initializeStates() {
HashMap states;
// put code here to initialize the hashmap via jdbc, xml parsing,
whatever...
return states;
}
}
Then the first time you reference the States class it is automatically
initialized. After the first time it is referenced, everything is cached.
"Thinh Doan" <[EMAIL PROTECTED]> on 04/22/2002 03:24:35 PM
Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:
Subject: RE: Where is it best to populate default form bean collections et
c?
We did it using an init servlet, run when the app gets loaded and stay in
app. scope.
Thinh
-----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]>
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
