> -----Original Message----- > From: Matt Ho [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 20, 2003 5:37 AM > To: [EMAIL PROTECTED] > Subject: RE: [OS-webwork] Proposal: Removing the Action Interface > > 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()?
Yes, I'm arguing for multiple entry points. But I'm not sure why we have to limit what those entry points can be called? I agree that it's nice to have a convention for which methods are entry points, and the command stuff I'm proposing would have defaults of the current naming scheme, i.e. execeute() is the default entry point, and doCommandName is the default entry point name for defined commands unless you declare a different method name. > > 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. The difference being here that different development shops can come up with their own naming schemes using my proposal, or they can choose to use the default doCommandName naming scheme. > > * 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. This is a documentation issue, IMHO. > > * 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. This is a valid concern, but one which is valid with flexible naming or fixed naming. Every shop will need to define naming standards, or just use the default naming standards. > > * 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. Possibly, but if that project thinks so, then they can choose to use the default. > > 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 How about if I implement the CommandDriven pattern as a core part of Xwork, then we can take a look at it and see where to go from there. ------------------------------------------------------- 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
