Don, I was refering to phase I really, whether the starting point is Webwork or Webwork + XWork.
Also, it seems from the documents on the project (if I am not incorrect) that XWork would still be a strong part of phase II and that there are Struts centric modifications to it that we might want to do, which strengthens the move over now argument. Also, could you clarify: "The first Ti prototype was going to be built on XWork, but I ended up just using WebWork itself since it did everything I wanted and was very easy to build upon." Does that mean that you removed the XWork dependancy from the Ti prototype or that you included WW in addition to XWork? Thanks, Gabe ----- Original Message ---- From: Don Brown <[EMAIL PROTECTED]> To: Struts Developers List <dev@struts.apache.org> Sent: Thursday, March 30, 2006 12:22:01 AM Subject: Re: [Struts Ti] XWork? Gabe wrote: > I wanted to answer these two comments by Ted. Whether to bring XWork is a > very important decision to make ASAP, because it is about how we define > Struts Action 2.0. > > Struts Action 2.0 = Webwork > > - or - > > Struts Action 2.0 = Webwork + XWork > While I'll let other XWork/WebWork folks weigh in on the XWork issue, I want to quickly make the point that this equation is incorrect. The original vision of Struts Action 2.0 started as Struts Ti. It was a collaboration of Beehive, WebWork, and Struts folks looking to write a simplified, Action 2 framework that leveraged the strengths of each. The first Ti prototype was going to be built on XWork, but I ended up just using WebWork itself since it did everything I wanted and was very easy to build upon. Spring was included into the discussion and soon "Clarity" was born with the idea of merging the four frameworks, however that proved too big of task for those involved. Ted threw out the idea to WebWork for their team to merge forces and work on Ti, and that's how the merger started. From the beginning, the goal was to create a project that simplified the developers task of writing web apps though less configuration and more modern features, and combining efforts is how we plan to accomplish this. While yes, we might hold off on new fancy features for now so we can get the first versions out quickly to the community, the goal was not and has never been a simple "rebranding" of WebWork. I'm sure you didn't mean it that way, but I wanted to take this opportunity and correct a misconception that seems to be going on around this project. Our goal is to create a new simpler, more feature-rich, developer-oriented framework leveraging all we've learned from Struts, WebWork, and other frameworks out there. Carry on :) Don --------------------------------------------------------------------- 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]
