Hi again
a related question. if I load up the data I need from within a plug in
and store it in the application scope, is this an acceptable
sepatation of "view" and "Model" as long as I am doing so from a
service?
Remember, this app architecture I'm using has a "service factory"
(which was set up from within a plug in), and the way all the data
access is done is from these "services".
Does that make sense? Essentially, I'll add a section to the init()
after this service factory is set up that uses the service factory to
instantiate a service whose purpose it is to pass back Application
Level data (I use the example of state codes, common to all users)
which I will then store in the application scope.
Am I making sense?
My goal is to keep this as simple as possible by introducing as little
complexity as possible
Dave J
P.S. I mean no disrespect to people who have suggested other ways of
doing this, I'm simply proposing what seems like a simple solution,
and wondering is it seems drastically wrong, or if it's reasonable.
thanks to everyone for the input!!!!!
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]
