You make some good points, so I'll add my 2c:
1. The chain logic should be separate from the application logic, which could, however, use common-chain. I'm fine with using a chain command to replace Action, as long as it can be made clear the line between the two processes. One defines how all requests should be processed, and the other, how this individual request should be handled.
2. Personally, I don't think an interface that has a single execute method that gets the context for an Action type is a good solution (or current Action's for that matter). To me, there are two different, yet valid approaches to the Action concept:
a. A single class which combines the request logic and request "model", or as we call it, ActionForm. Best implemented in WebWork2, the action class has setters for the form data, but also an execute() method containing the request's logic code. This pattern is great for simplicity and keeping the action code servlet api independent, since the framework handles calling setters so the class can deal with regular Java types. The disadvantage of this pattern is, for a moderately complex application, you have a ton of classes.
b. Multiple action methods per class ala DispatchAction. This pattern is better in the current Struts world where the form is separate from the action, so the action is rather small. DispatchAction (and its children) allow you to group related actions into one logical unit, cutting down the class count. In this pattern, the ActionContext and ActionForm are passed into each execute-type method, letting the action pull out what it needs. This disadvantage to this approach is your action code is very tied to its environment (ActionContext in this case), and you still need to define your forms somewhere else.
To me, having a single class with an execute(ActionContext) takes the disadvages of both approaches without the benefits of each; the worst of both worlds if you will. I believe the best solution is similar to JSF where the action class is combined with the form, and yet the action class can be any POJO that can contain any number of request processing methods. Ideally, this action/form class would be able to span multiple pages to define a logical process, possibly using Java continuations.
Don
Frank W. Zammetti wrote:
Just as an interested third-party observer, I hope you don't mind two interjected points here...
1. A few years back I was involved in the development of a framework where I was working (this was just around the time Struts was hitting the scene). We in fact did what Joe is talking about: abstracted away the fact that the controller classes (synonymous with Actions) were working in a servlet environment. We did this exactly as you are talking about: a context class that was passed around instead of request and response and all that jazz. Doing this in Struts will be a major boon in terms of more easily unit testing code and reusing parts of a system in other environments, i.e., it should be easier to slap a Swing interface over what was formerly a web front-end with the application itself working as it did before. I believe this change will be worth whatever pain it may cause in the short run, without any question in my mind. I suspect anyone that understands the benefits of this change in the user community will agree whole-heartedly, so while the concern about changing core Struts classes is perfectly valid, I personally would put it aside in this instance believing that any difficulty it causes is worth it.
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, whatever that chain may be, because then you could have a chain containing multiple Actions (which I actually thought was already on the list of new capabilities?), and not have to worry about dealing with anything other than Commands. In other words, removing the whole concept of an Action in favor of nothing but Commands really simplifies things a little bit: one less concept to think about. The argument against this I would think is backwards compatibility, but it sounds like Joe's approach deals with that already, so going the extra step or two and making Actions true Chain Commands makes sense to me.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
