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.
It's more than possible I'm not quite getting the whole idea here :) But, regardless of that... All I have really been thinking about is something along these lines...
<action path="/app/page1" type="com.omnytex.actions.Page1Action">
<forward name="default" path="/jsp/page1.jsp" />
<setupItem class="com.omnytex.actions.Page1Setup" method="setupMethod1</setupItem>
<setupItem class="com.omnytex.actions.Page1Setup" method="setupMethod2</setupItem>
<setupItem class="com.omnytex.actions.CommonSetup" method="commonSetupMethod1</setupItem>
<setupItem class="com.omnytex.actions.CommonSetup" method="commonSetupMethod2</setupItem>
</action>
That would result in Page1Setup.setupMethod1() being called, followed by Page1Setup.setupMethod2(), followed by CommonSetup.commonSetupMethod1(), and lastly CommonSetup.commonSetupMethod2(). That would actually fulfill the goals I had. Would you find that difficult to manage?
The one thing your suggestion has over this is the dynamic nature of the configuration. That would be nice indeed :) However, since Struts configuration information is frozen anyway, I'm not sure it would be a big deal.
This would just be added to ActionMapping, so it's a fairly simple and straight-forward change. Then just a modification of RequestProcessor and we should be all set.
Something else that might be nice to do here is have Struts instantiate each of the classes referenced in all <setupItem> tags throughout struts-config.xml. Upon doing so, call an init() method. This would allow them to maybe get all the data they would need at the start, instead of having to do it with each call to a setup method. So, just like Actions, they would be shared. The down-side to this is that, like Actions again, they would have to be thread-safe. People might be tempted to call init() themselves to update the data, but that would be a Bad Thing(tm). I'm not sure there is a good, clean way to allow for that generically. Any ideas?
What do you think of this approach? I realize it doesn't have all the benefits of your idea, but I frankly think it would be easier to potentially get some traction with as far as getting added to Struts goes simply because it's not that big a change to Struts itself, not that big an addition. But, I think it would open up a world of flexibility for people. Thoughts? :)
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
