Don Brown said: > 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.
Fair point. I presume the Action execution, as it stands now, is one link of the overall "request processing" chain... I might go so far as to make it so that defining an Action is actually defining a chain, and I mean that it ALWAYS is that, even if the majority use case is a chain with a single command. Subchains I believe are not a problem from my reading, and that's all this would be. > 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. While I am usually a big fan of cutting down class count, this is one instance I wouldn't be happy doing so. I actually think the separation of Actions and ActionForms in Struts now is excellent, although I've never been thrilled with the name ActionForm, but that's not a major point :) This is actually one of the mistakes we made with the framework I was involved with... if we had thought of such a separation, I believe the end result would have been superior. Even if there are examples of where the combined approach works well, I think keeping them decomposed allows for more flexibility, which is never a bad thing :) > 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. All of our controllers (Actions in Struts parlance) were essentially DispatchActions, although we took a different tact with it... when you defined your "mappings", you specified the class, as you do in Struts, but we also defined the method to be called for a given mapping. What this allowed us to do is make all our controllers POJOs, and didn't require any parameters to make it work. Everything was declarative. This has pluses and minuses, but I think the pluses outweigh the minuses. I wonder if Struts should consider such a thing? Make it so Actions don't have to implement any interface or extend any class, and add the method to the mapping. That has the effect of "giving the inheritance tree back to the application developer", i.e., no more forced inheritance squashing the one chance at inheritance an Action has. > 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. Interesting... I actually see that as being the BEST of both worlds :) I of course leave open the possibility that I completely missed something, but failing that it's a matter of perspective I suppose :) Frank > 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] > > > > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
