See below. > -----Original Message----- > From: Matt Ho [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 19, 2003 6:46 PM > To: [EMAIL PROTECTED] > Subject: RE: [OS-webwork] Proposal: Removing the Action Interface > > > -1 > > I think one of the challenges when developing a good system > is deciding what its boundaries should be. I think WebWork > makes an amazing command pattern framework and has the > potential to be widely adopted because it's easy to grok. > > Here are my primary issues against this: > > * The Action interface provides runtime checking and allows > for a design by contract paradigm. Not only does this > prevent the "execut" problem that Patrick mentioned, but it > also provides an excellent ground for new developers trying > to understand the system.
The thing that we're missing here is that Webwork 1.x already DOES what I'm talking about, but it's just got the method names hardcoded based on a pattern when you use the CommandDriven Interface and a subclass of ActionSupport. It uses reflection to find a method name doCommandName. What I'm proposing is to make this the default behavior and make the CommandDriven way the way the ActionConfigs work, with a default Command mapping for the execute() method. > > * It's a halfway solution. The existing solution defines (a) > a well understood paradigm, the command pattern, along with > (b) the method signature. The proposed solution does not Unless you use the CommandDriven pattern. > require any particular > paradigm, but does require a partial method signature, void ...() If > arbitrary method invocation is the way to go, I would suggest > allowing the entire method signature to be reworked. > > * cost/benefit ratio is poor. The amount of conceptual and > configuration complexity being added doesn't seem to justify > the benefit I get by being able to invoke arbitrary commands. > I think this gets to my next point ... > > * diffuses xwork's focus. XWork is a generic command pattern > framework, and shaping up to be a great one at that. If I > wanted a generic aspect framework for POJO, I'd wait for > JBoss4. If I needed one now, I'd use BCEL or nanning. I > feel one of XWork's strengths is that it focuses on doing one > thing and doing that thing well. > > Having said all that, I would be more than happy to volunteer > to write an interceptor that would allow execution of > arbitrary methods. That way, anyone who wanted to execute > arbitrary methods could and we wouldn't need to modify the xwork core. > Let's break this into 2 discussions: 1) CommandDriven. I want the CommandDriven pattern to be core to Xwork, not just an implementation detail of ActionSupport like it is in Webwork. I think it's immensely powerful and useful. It allows you to have one Action with multiple entry points without having to do a big if-else block to do this yourself. It lets you have the same Action for the entry to a form, when you don't want validation or to try to execute code depending on set values. With the CommandDriven pattern, you define a command name with an alias you can call it, and this will call doCommandName using reflection. Once you're doing reflection for an arbitrary method name, why not make the method name configurable (while still defaulting to the old doCommandName)? 2) Removing the dependence on the Action Interface Once you've made it possible to configure methods to execute on the Action, it's a small leap to make this the default behavior where, if you give an alias name for your Action in the <action> element, this is configured as a Command with a method name of "execute" and you use reflection here, just like anywhere else with commands. At this point, the Action Interface can be optional (at least, if not gone altogether). The advantage here is consistency, and not doing things one way if it's a command and another if it's the default. This would STILL be a generic command pattern, just made more flexible. The benefit of the CommandDriven pattern is great. The benefit of losing the Action Interface is more subtle, but it really allows for more flexibility and makes your code less tied to Xwork, and once it becomes mostly unnecessary, it just seems like an extraneous carryover. Jason ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
