Frank
I see what you mean. I was assuming I'd just store the data in a
hashtable or something in the Application Context
I have stupid question...where is your AppConfig actually getting
stored? I'd think you'd need to do the above at some point and do a
getServletContext().setAttribute( AppConfig, "myAppInfo");
oh boy what am I missing.. or was that implied.. OR did I miss your
hwhole point? I really hope it's not the last one ;)
For this app it's safe to assume we'll always be using struts (btw)
On Mon, 14 Feb 2005 14:15:28 -0500 (EST), Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> Using a plugin only tells you WHERE your going to read the information in,
> not where your going to STORE it. I think that's the question you really
> want to ask. Plugins are pretty standard practice when dealing with
> Struts, but if you have a concern that you might not be using Struts at
> some point, you might want to do something else.
>
> In any case, where you put the data is the question. I'd still put my
> vote down for a static "storage" class. I do that, read the data in a
> plugin, stick it in the storage class, and I'm done. The storage class is
> pretty much nothing more than this:
>
> import java.util.HashMap;
> public class AppConfig {
> private static HasMap config = new HashMap();
> public static void setConfig(HashMap config) {
> this.config = config;
> }
> public static HashMap getConfig() {
> return config;
> }
> }
>
> I start my plugin by doing:
>
> HashMap config = AppConfig.getConfig();
>
> ...then read in whatever data I need, shove it in config, and final do:
>
> AppConfig.setConfig(config);
>
> Again, so long as this data isn't going to change, and it's not a huge
> amount of data, that's all there is to it. I don't know if this would be
> considered "best practice', but it's certainly "common practive" AFAIK :)
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> On Mon, February 14, 2005 2:08 pm, David Johnson said:
> > Ah!
> >
> > After reading up on the Struts Plugins, I have the following question
> >
> > Are struts plugins a perfectly acceptable way to handle Application
> > level caching? How about best practices-wise?
> >
> > Thoughts?
> >
> > D
> >
> >
> > On Mon, 14 Feb 2005 11:03:24 -0800 (PST), Martin Wegner
> > <[EMAIL PROTECTED]> wrote:
> >>
> >> A PlugIn works nicely as well. I am not sure which is the recommended
> >> Struts practice.
> >>
> >>
> >> --- Wendy Smoak <[EMAIL PROTECTED]> wrote:
> >>
> >> > From: "David Johnson" <[EMAIL PROTECTED]>
> >> > > I have a need in an app I'm working on to cache data that is valid
> >> and
> >> > > shared across users, like standard country codes, region codes,
> >> > > industry codes... stuff like that.
> >> > >
> >> > > What's the best way to do that with my struts 1.2 application? Is
> >> > > there something built in that I'm not aware of that I can leverage
> >> or
> >> > > any best practices you guys can point me toward?
> >> >
> >> > I use a ServletContextListener that puts a bunch of Maps and other
> >> > resources
> >> > in application scope. (Then I use a HttpSessionListener to set up
> >> > user-specific things.)
> >> >
> >> > --
> >> > Wendy Smoak
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > 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]
> >>
> >>
> >
> >
> > --
> > -Dave
> > [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
--
-Dave
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
