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 Important note: this does not mean merging Webwork and XWork, just making them two subsections of Struts Action 2.0. Other important notes: The functionality of Struts 1.* is equivalent to XWork + Webwork not just Webwork, and without XWork SAF 2 would be an action framework without an action class. Making that decision is very important in determining other things as they come up. The recent example is package naming. If we put Webwork code at some.struts.action2.root package, then where would XWork go? I strongly suspect there will be other decisions made that will similarly be better done if we know whether XWork would be a part of Struts Action 2.0. Recent events support the Struts Action 2.0 = Webwork + XWork argument. There was the question of whether a ForwardAction should be created or how it related to XWORK's ActionSupport. I suspect that a lot of these questiosn of how Struts Classic compares to XWork will need to be asked in the future not only by struts developers but also by those interested in moving from Struts Classic to Struts Action 2.0. We will get tons of questions about how Actions / configuration compare from Struts Classic to XWork's, want to provide migration strategies from struts-configs to xwork-configs from struts ActionSupport to xwork ActionSupport. This means that advantages of moving XWork at the same time as Webwork are: 1) one users list to deal with user comments on both Action issues (XWork) and Tag/view issues (Webwork) 2) The ability to coordinate releases or add features (For example the ForwardAction) that will help Struts Classic users migrate to Action 2. (Currently, it should be noted, XWork and Webwork releases happen pretty much simultaneously with an XWork version coming out and then a Webwork.) 3) The ability for documentation for Action 2 to more gracefully contain integrated documentation on its action structure. I think going forward, if you are opposed to bringing XWork in immediately, then the following questions should be answered: 1) How would XWork questions be answered? Would the struts list serve as a second xwork mailing list or would questions be forwarded to opensymphony? 2) Would large amounts of struts documentation serve to duplicate XWork documentation or would struts developers be forwarded to xwork documentation? It is important to decide those issues, because for a new 'revolutionary' approach, we wouldn't want to switch midstream how users approach XWork classes (start out with open symphony ActionSupport and then have to move to a struts one for example), since they are so integral to the app. I hope this clarifies why I think this is a decision we should make now. Gabe ----- Original Message ---- From: Ted Husted <[EMAIL PROTECTED]> To: Struts Developers List <dev@struts.apache.org> Sent: Saturday, March 25, 2006 5:22:47 PM Subject: Re: [Struts Ti] XWork? On 3/25/06, Gabe <[EMAIL PROTECTED]> wrote: > I'm sure I could come up with more reasons, but this is a good start to this > discussion. I don't think anyone would have a problem with this, Gabe. It's just a matter of whether we need to bring XWork and WebWork through simultaneously, or whether we can do them one and then the other. (If that's what the XWork developers would like.) As I understand it, XWork is being used in applications other than WebWork. If XWork had a stronger self-identify, other applications might find it helpful too. ----- (also from a different message by Ted) As to the package naming, did anyone want to change their vote to followup on Gabe's suggestion? Otherwise, it looks like the conventions suggested by Rainer have the most support. I don't know if we want to bring XWork into the ASF now, later, or never. Of course, it's a great package and I'm sure we'd love to have it, if the XWork developers would like to donate and support it. There would also be the question of whether XWork is something that we would maintain here, or whether we might want to propose it to the Jakarta Commons, where it might find a broader audience. -Ted. --------------------------------------------------------------------- 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]
