I'm -1 on the draft proposal. The vast majority of the API as I read it is to support Bob's proposal of how to deal with XWork. As Patrick stated before (paraphrase) the three proposals are: 1) Move XWork over as a seperate project under the umbrella of Struts Action 2 (Webwork=>Struts "web" and XWork=>Struts "core") 2) Create an adapter layer for Struts 2 developers to use without directly interfacing XWork (Bob's proposal) 3) Leave XWork where it is and use XWork's API directly in Struts Action 2
The public API presented mainly implements #2, which has not yet built a consensus that it should be used. In my view, the problems with #2 are: 1) It creates an adapter code layer that adds little functionality but requires maintenance. For example, if something is added in XWork, then a change in Struts 2 will generally be required for that change to be usable. 2) If it does add functionality, it blurs the traditional seperation of roles between XWork and Webwork. The adapter layer risks becoming a second judgement layer on what should or should not be in XWork. I think those decisions should be made in the XWork project directly. 3) If we are going to use XWork's API so directly and are worried about it being called "opensymphony.xwork" rather than "apache.struts", we should simply move XWork over as in proposal #1. 4) It creates a divide of those things that are part of the Adapter pattern layer and those that are not. Those that are not become more obscure and undocumented. Thus, while I applaud Bob and Patrick for putting out a vision in code, since it appears to me that 90% of the API simply supports proposal #2, we should discuss that proposal instead first before creating an API that supports it. Gabe ----- Original Message ---- From: Patrick Lightbody <[EMAIL PROTECTED]> To: dev@struts.apache.org Sent: Wednesday, May 3, 2006 10:01:58 PM Subject: [action2] Public API first draft Bob and I have been going over the new public API proposal. It has been designed to simplify Struts and abstract away XWork complexities that aren't needed. It is far from complete, but we wanted to get some early feedback. We'll likely be talking about this stuff a lot more during JavaOne, but we'd like to start the discussions now. The code is checked in under the action-api module. Assuming you've got the basic Maven build running, you can generate the JavaDocs (which might make seeing the API easier) by running: mvn javadoc:javadoc >From the action-api directory. You must have run "mvn install" at least once >before for that to work. --------------------------------------------------------------------- Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=56817#56817 --------------------------------------------------------------------- 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]
