On Mon, February 14, 2005 2:53 pm, David Johnson said:
> I think I get it. Static classes I get, but I guess I didnt consider
> that any static member of a static class is always accessible. It
> still strains my brain a little, actually, but I guess it makes sense.
Yeah, static is one of those things that people tend to get confused about
early on. Don't worry, time will make it rather clear and you'll
eventually wonder how there was ever a time it didn't make sense :)
> so you'd recommend this above creating some hashtable and just
> plunking it in Application scope then. What are the advantages of this
> way over the "sticking it in app scope" method?
Hmm... Honestly, I never thought much about benefits over anything else :)
Thinking about it NOW though, the only one that comes to mind is that
"sticking is in app scope" is tieing you to a servlet environment. Think
of it this way... ideally, each part of your application should be
testable on it's own, even OUTSIDE Tomcat or whatever servlet container
your using (I think you said Tomcat and maybe Weblogic eventually?)
If you just have a static class, it's a POJO (Plain Old Java Object),
which means you can test it to your hearts' content without Tomcat.
Not this the class I posted would need much testing :) But still.
> My only issue is that the application already has a few things hanging
> off the ServletContext as attributes, and it would seem inconsistent
> for maintenance I suppose..
That's a fair point, especially to someone like me who tends to be overly
anal about consistency :) I would argue that you may not want whatever
you have hanging off ServletContext to be there either, for the same
reason as above. If you know your app would never need a different
presentation then it's not really a concern, but building flexibility into
a design at all levels makes life easier later when the inevitable scope
creep comes out to bite you :)
Frank
> ----Separate thing-----
> what about the problem where some of the stuff I'd need in my listener
> is actually being set up in a struts plug-in (that's the way it is
> currently)
>
>
> On Mon, 14 Feb 2005 14:34:23 -0500 (EST), Frank W. Zammetti
> <[EMAIL PROTECTED]> wrote:
>> On Mon, February 14, 2005 2:26 pm, David Johnson said:
>> > Frank
>> >
>> > I see what you mean. I was assuming I'd just store the data in a
>> > hashtable or something in the Application Context
>>
>> That's what I think Wendy suggested, and it's probably a better idea
>> than
>> what I do frankly :)
>>
>> > 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
>>
>> No question is stupid :)
>>
>> > 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 ;)
>>
>> Your forgetting some basic Java is all (and everyone does it from time
>> to
>> time, regardless of what anyone might claim :)
>>
>> A member of a class that is static is always present in the CLASS,
>> independent of any instance of that class. For instance:
>>
>> public class myClass {
>> public static int PI = 3.14159;
>> }
>>
>> Now, if you have another class that wants to use PI, you just do:
>>
>> public class test {
>> public void showPI() {
>> System.out.println(myClass.PI);
>> }
>> }
>>
>> No instance of myClass is created, yet you can access the PI member of
>> it
>> through the instance of the CLASS... That's sometimes confusing to
>> people... The way I learned to think of it is that the JVM (the class
>> loader specifically) in a sense does automatically creates an instance
>> of
>> the myClass class, but an instance that ONLY contains the static
>> members.
>> That's not actually what happens AFAIK, but IN EFFECT it is.
>>
>> As long as the two classes are loader by the same class loader, your
>> good
>> to go.
>>
>> > For this app it's safe to assume we'll always be using struts (btw)
>>
>> Then a plugin is safe. But, as others have said, it's just about as
>> easy
>> to do it other ways, so you may as well have one less Struts tie-in.
>> And
>> as Vic I think said, DAOs are the best-practice (one I haven't had cause
>> to use yet myself, but I in *no way* disagree with his point).
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>>
>> >
>> > 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]
>> >
>> >
>>
>>
>
>
> --
> -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]
