Doesn't mean that there couldn't be an additional (empty) hook execute(ActionContext) implemented in Action (or in "CommandAction" extends Action), for the users to extend it.
my 2 cts.
Reducing number of config files is a most worthy goal, so +1 on a way to use a simple command without chain-config.xml
The real kicker for me in this goal would be autodiscovery of all struts-config files in the war, like Eclipse discovers its plugins, on startup (say, look for all xml's that use struts_1_3.dtd).
Wolfgang Gehner
Joe Germuska wrote:
At 2:05 PM -0800 2/13/05, Don Brown wrote:
I don't mind sticking ActionContext everywhere as it is better than having the code rely directly on the servlet api, but since we are talking about modifying Action, why not get rid of this "must extend Action" stuff and make Action an interface? IMO, Struts core should depend on this new interface, say Actionable, where Action would be an implementation of this interface. Since the methods of Action like saveMessages have been moved to ActionContext, we can safely get rid of Action, a passing I won't soon be missing. :)
At 6:28 PM -0500 2/13/05, Frank W. Zammetti wrote:
2. Joe mentions that an Action starts to look like a Chains Command at this point interface-wise, but that an Action isn't intended to be used as part of a chain. This raises a question in my mind: why not? I admit to not being completely up on chains and all the changes you guys are making in the new Struts branch, although recently I've tried to play some catch-up :) So, why couldn't an Action be seen as a link in the complete "request handling" chain that Struts implements? I would think it very powerful to just look at an Action as another Command in a chain
Well, since you can already use an <action> element to cause the invocation of a command (or chain), I think it would be redundant to make "Action" a command for that purpose. However, if we go ahead and change the signature to Action, the net effect will be about the same, as the "ExecuteAction" command will certainly pass in the same chain (Action)Context which would be passed in to Action-implementing-Command. The only real difference would be whether or not the Action class would be given the ability to return "true" to indicate that the chain processing should go no further.
So, as it stands now, the main benefit of privileging "Action" is that you can specify the processing class in struts-config.xml, instead of having to go to another file to set it up. That's a decent benefit, I'd say -- we don't want to make configuration a nightmare.
Don sent a more substantial proposal between when I wrote most of this and when I sent it, so I'll save reactions to that until I have a chance to digest it. My initial reaction, though, is that with the CoR request processor, it's feasible to support multiple parallel models: most simply, in a universal-per-app environment where you simply put different commands in the chain, but also quite possibly in a multiple-approach-per-app design where the chain has a way to recognize which processing model to bring to bear.
Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
