Leon Rosenberg wrote:
Well in this case the action was instantiated a business object reference (like ejb remote) for later invocation of business methods in execute. I mean, I have to do it somewhere and it is tied to an Action, so the constructor seemed to be the appropriate location for it. However, our current CORBA implementation (JacORB) actually associates a separate connection with every remote instance (which is very ugly btw), so we started to move all (but not all yet :-)) remote references to the base action as private static variables with protected accesser to it.
I would have been thinking a singleton factory class, but clearly without knowing all the details of your project I'm just talking theory here. Big difference between that and where the rubber meets the road often times :)
The idea of instantiating an Action in another and calling methods on it, even if calling execute() itself, is not inherently a bad thing. In fact, it's one fairly elegant solution to the "setup Actions" problem (i.e., you do an Action and then need to do some setup for the next screen... do you forward to an Action that just does screen setup? This is a good place to think about instantiating that "setup" Action and calling execute() on it yourself). The fact that this causes problems in your particular case indicates you may not have a good separation of responsibilities.
Hmm, I think this is something better solved by inheritance? I mean instantiating an action is like instantiating a servlet, since an
action is a method extracted from the servlet (you know the dark ages,
before struts), and instantiating a servlet was never a good idea, because
they are managed by the container... and so should actions, shouldn't they?
Can't say I ever thought of it that way :) Not a bad point... I think you could view Actions as helper classes to the servlet though, and in that respect there would clearly be nothing wrong with instantiating and using one yourself. The idea of not instantiating your own servlet I think has more to do with the idea of letting the container take care of request processing, so it's a little different. I suppose you could view Struts as something of a container and make the same argument, but I think that might be stretching things a bit :)
I suppose there are some vaguely hackey ways you could stop the Action from being instantiated by anything other than Struts, but I would frankly look at solving this from a design perspective instead.
Already done :-)
Very glad to hear it! :)
Leon
Frank
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
