> > Interesting... Honestly, when I read through it at first, my > reaction was "geez, that's pretty complicated for a > relatively simple concept", but upon a second reading I > realized it wasn't all that complicated.
No, actually it's a one-liner in the constructor, and the code you need for proceeding configuration, which you need either way. > > However, it seems like we already have something along these > lines: the collection of ActionMappings read in at > application startup. I'm not sure about introducing a whole > new collection of objects, and management components to go > along with it. I find it hard enough to manage all the config files I have to manage right now (struts-config, resources, tiles-definitions, factories, and so on), I would be the last one to introduce one more. But since each action knows ist configuration object's reference (filename, url, somehow resolveable reference), there is no explicit collection anywhere. As soon as an action requires a configuration it's been read and is available. If no action requires a configuration it's not present in the app. > > I like the idea of the Action in a sense inherently knowing > which setup object to get. That is intriguing. Noone can know better :-) > But, I think > it goes against one of my stated goals, that being that it > might not just be a single method in a single class that > deals with setup for a particular page. You might in fact be > dealing with a number of different object and a number of > different methods in each. If we declaratively "attach" an > object to an Action whos purpose is to do setup, then you > might have code duplicated in various classes (imagine a > dropdown that appears on three different screens). Sure, you > could have the setup object call some object that has that > common code, but isn't that making things more complex rather > than more simple? You could attach same setup object to all three actions, couldn't you? This would solve the problem? And you could attach multiple objects to an Action. But I think, an action which requires more then one configuration object is probably to complicated, and should be refactored :-) > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > Leon Rosenberg wrote: > > You could use / write a common configuration framework, > which would be > > instantiated by the action servlet, and where all configuration > > objects are stored / managed. An action would then obtain it's > > specific configuration object in constructor, or even better in > > execute(). Last one would allow to change the configuration on the > > fly, without restart or anything. > > > > Actually we are using something like this but for services. > It's based > > on propertyfiles and a simple watcher thread, which checks all > > registered files, and if they changes calls: > > notifyConfigurationStarted(); > > setProperty(name, value) for each property in file > > notifyConfigurationFinished(); > > > > it's absolutely simple, but works superb, we are using it to > > reconfigure caches, switch databases switch legacy systems > on and off. > > > > Is it IoC enough for you?:-) > > > > Regards > > Leon > > > > > >>-----Ursprüngliche Nachricht----- > >>Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED] > >>Gesendet: Sonntag, 6. März 2005 00:14 > >>An: Struts Users Mailing List > >>Betreff: Re: Eliminate Setup Actions > >> > >>Sure, that would work. But, then you are limiting the developer to > >>basically one setup per class, or forcing them to do some work that > >>Struts really should be doing... > >> > >>If I were to add something like this to Struts (and I have enough > >>interest in this idea that I'd love to persue it, assuming there is > >>some general interest), one of the requirements in my mind would be > >>the ability to call any number of setup methods per mapping. > >> > >>For instance, maybe I have a page with 10 different > dropdowns. Maybe > >>I determine that the way I want to implement that setup is > to have ten > >>different methods in my setup class and specify them all to > execute in > >>the mapping. > >>Sure, I could call all ten of them from the constructor, > but that just > >>*feels* like a bit of a hack to me. I'd prefer a more IoC-esque > >>approach, and this feels like the exact opposite. I'd want > to be able > >>to explitidly declare the ten methods I want executed (and in the > >>stated order of course) rather than having to code that > functionality > >>into the setup class itself, which is what I'd be forced to > do in the > >>constructor (ditto for a static block). > >> > >>There is a debate in my mind whether the setup class should have to > >>implement some given interface... It makes sense to do so > because then > >>Struts can be sure the class is of an appropriate type for the task. > >>But, to allow for multiple setup methods the interface > would have to > >>be defined to include setupMethod1(), setupMethod2(), > >>setupMethod3() and so on. That's pretty obviously a bad > design. So, > >>I imagine the interface would pretty much just be a tag > interface, and > >>we would have to assume that if the developer implements the > >>interface, then whatever methods are present in the class are meant > >>for setup. Like I said though, there's a bit of debate in > my own head > >>on this point right now. > >> > >>-- > >>Frank W. Zammetti > >>Founder and Chief Software Architect > >>Omnytex Technologies > >>http://www.omnytex.com > >> > >>Leon Rosenberg wrote: > >> > >>>>... I figured you'd specify > >>>>the class and method to call, although even easier would be > >> > >>to write > >> > >>>>an actual SetupAction class, or something along those > lines, with a > >>>>known interface that all these classes would have to > >> > >>implement, then > >> > >>>>you would just specify the class and Struts would know what > >> > >>method to > >> > >>>>call. > >>> > >>> > >>>Erm, what about the constructor? Or the static{} part? > >>> > >>>Regards > >>>Leon > >>> > >>> > >>> > >>> > >> > >>------------------------------------------------------------ > --------- > >> > >>>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] > >> > >> > > > > > > > > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
