This could be a valuable comment... or maybe it won't be :) ... this is
coming from the perspective of an experienced Struts developer who has
looked at and worked with Webwork just a bit at this point, so take it
for what it's worth...
I didn't, before some reading I just did, have a separation in my mind
between Webwork and XWork. What I had in my own mind as an
understanding of Webwork was really the combination of Webwork and XWork.
From that perspective, I'm not sure I see how *not* bringing XWork over
with Webwork would yield something comparable to Struts. It seems like
if Action2 is really going to be the next Struts, it necessarily has to
be both Webwork and XWork combined, otherwise it's something... less.
I suppose there might be ways to bring Webwork over without XWork
initially, but to me that seems like more work in the long run (maybe
not for me, but I wouldn't think anyone wants to do more work than is
necessary :) ).
I have to believe that the Struts team has a better understanding than I
do of what Webwork is and how XWork relates. But can the same be said
of the Struts user community? Could it possibly be that even the
Webwork community doesn't fully understand? I ask these rhetorically
only to illustrate the point, which is that I suspect that for a lot of
developers, there won't be a distinction between Webwork and XWork, like
there wasn't for me, so it is probably best for XWork to come over too,
and concurrently with Webwork.
Besides, what is the alternative if it doesn't? Will the Struts
download page point you to the XWork download page at OpenSymphony as a
dependency?
I hope that perspective is useful :)
Frank
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
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]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
