I guess I'm a bit confused but is this API the only supported route or are their plans to support existing WebWork/Xwork code? I'll be honest and say that I need to go through the API and consider each point before I make a complete judgement. However, at first glance, this deviates far enough from existing XWork actions to leave me a bit concerned.
In regards to the implementation of the API where did ResponseAware go? While not elegant there are times where it is useful. (admittedly I use an interceptor for this for example http://confluence.twdata.org/display/WW/HTTPS+and+IE+Issues so it may be a mute point.) - Eric On 5/4/06, Gabe <[EMAIL PROTECTED]> wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
