[Struts Ti] XWork?

[Gabe <gj...@yahoo.com>]

Hi! I don't think I have posted to this list yet. I am Gabe, XWork/Webwork developer. Now that I see that discussions are starting about the merger I wanted to bring up an issue that I brought up on the WW boards that was tabled for just this moment (or after incubation?)

The issue is whether XWork should be moved over with Webwork to Apache and be merged as part of Struts Ti. I am in favor of XWork being merged with Webwork and it all being part of Struts Ti, where perhaps there are two jar files and two package roots, say strutsti.web and strutsti.core, for example.

My reasons are the following:

1) Most of the "meat" of developing a "webwork" application really revolves around the XWork classes: ActionSupport, Interceptor, AroundInterceptor, the converter classes, ObjectTypeDeterminer etc. Also, the equivalent in webwork for struts-config.xml is xwork-config.xml. Webwork itself, as I understand it, is mostly the view technologies and plugging in XWork for the web.

2) Documentation - Currently, Webwork and XWork documentation are already very much intermingled. Because of reason #1, if you look at Webwork documentation it includes all the information of how to use the XWork classes, because that is a very important part of developing a WW application. This has worked in the past, because people working on one project are usually working on the other, meaning that it is easy for the documentation can be easily used across projects. I would think if the two were at seperate organizations, then it would make that harder. 

3) That XWork is not specfically Web would help Struts Ti. The larger market of struts than webwork had will mean that people might be encouraged to write serious interfaces to other view technologies such as Swing. That you could write such an app that could have the different views would be a good selling point for Struts Ti to have.

4) Further evidence that XWork and Webwork are intermingled and should really stay together is that that there is only one webwork message board, none for XWork, as XWork questions are generally answered in the Webwork message board.

I'm sure I could come up with more reasons, but this is a good start to this discussion. 

Gabe




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [Struts Ti] XWork?

[Craig McClanahan <cr...@apache.org>]

On 3/25/06, Ted Husted <te...@gmail.com> wrote:
>
> On 3/25/06, Gabe <gj...@yahoo.com> 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.)


And that parenthetical comment is the key to this.  Nothing stops SAF
2.0(or Shale for that matter) from having a binary dependency on
XWork, even if
it is still maintained by the OpenSymphony folks. I would personally welcome
including this code base ... but whether it comes here or stays there has to
start with what the XWork developers want to do.

Craig

Re: [Struts Ti] XWork?

[Ted Husted <te...@gmail.com>]

On 3/25/06, Gabe <gj...@yahoo.com> 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.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org