> > * 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.
Internal code from the bowels of WebWork 1.x does not a design pattern make. *poke* *poke* *grin* > 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)? I think what you're arguing for here is allow for multiple entry points rather than arbitrary method invocations. While I don't necessarily agree with this approach, I'd be comfortable if we could come up with a standard implementation for this. What the Action interface does is to provide a clear marker that the execute method is an entry point. I'd be happy coming up with some other clear marker. For example, what if we prefixed all the entry points with 'execute' or 'do'; execute(), executeTransfer(), executeXYZ()? I think we'd get the following benefits: * When developers work on new code currently, they immediately know that execute() is the entry point. Having a prefix continues to allow them to know what the entry points are without having to constantly refer back to the configuration file. * Clear interface for people configuring xwork. Let's say I get this OSS package from the net that uses webwork and I'd like to use it in my project. A clear marker would again make it easy for me to integrate 3rd party packages b/c I know what to look for. * It also helps to alleviate dangers from refactoring. With markers, I know that I need to change xwork.xml if I change an executeXYZ() method. Without markers, it's much easier to inadvertently refactor something away that xwork was depending on. * Transferable knowledge (an extension of the first point). I think it's a Good Thing (tm) that I can go from one WW project to another without having to include the web layer in my ramp up time. With arbitrary method invocation, my guess is that localized conventions are likely spring up for how to handle the method invocation. Localized conventions for something this common are a Bad Thing (tm) in my mind. If you've got a strong opinion on arbitrary method invocation (as opposed to multiple entry points), a solution might be the following: - document execute() as the default method - developers are allowed to override this by saying something like execute="foo". execute="foo" would first look for a prefixed method such as executeFoo() or doFoo(), but then fallback to foo() if no prefixed method is found. - the documentation should Strongly encourage using prefixed methods or the default execute method > 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. Again, as long as we have a clear marker, I'm fine not using the Action interface as the marker. -- Matt Ho Principal Indigo Egg, Inc. http://www.indigoegg.com/ ------------------------------------------------------- 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
