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 like the idea of the Action in a sense inherently knowing which setup object to get. That is intriguing. 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?
-- 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]
