A key aspect of the merger is to create migration tools and bridge classes to make it very easy for teams to migrate existing Struts applications to WebWork. Perhaps it would make more sense to first create the migration layer as
as an extension to WebWork in the Open Symphony repository. Then, when the migration layer is ready, and the WebWork codebase is otherwise stable, we could bring the whole enchilada into the Struts repository (via the Incubator).

I do have the time and energy to kickstart the Struts/WebWork migration tools, but I don't want us to put WebWork "on hold" while we create the tools. Once we have a working migration layer, the move to Struts could happen very quickly.

To kick off the merger, I would suggest that we nominate Patrick and Jason as Struts committers, and Don and Ted as WebWork committers. Then, I'd like to create "mirror" versions of the Struts MailReader application, demonstrating best practices for Struts Action 1.3.0 and WebWork 2.2, and use the MailReader as the first migration test case.

More about MailReader ...

* http://opensource.atlassian.com/confluence/oss/x/PAM

-Ted.

Is anyone else besides Struts/WebWork committers allowed to take part in this discussion?

<Ted>
I'd like to create "mirror" versions of the Struts MailReader application, demonstrating best practices for Struts Action 1.3.0 and WebWork 2.2, and use the MailReader as the first migration test case.
</Ted>

What about Struts Dialogs implementation of MailReader? Will it be checked for compatibility by you or someone else, or should I do it myself and start crying wolf to bring back/retain needed Struts quirks? Or maybe I can rewrite Struts Dialogs for WebWork?
Umm... if I remember correctly, Jason did not like the idea of session-scoped inter-request data, when we had an argument on TSS over Redirect-after-Post pattern. Despite that this pattern is less relevant for ajaxified applications, it still makes a lot of sense for situations where client scripting is not allowed.

How about enriching the "classic" practice of pre- and post- actions with init-display-postback-reload approach a-la ASP.NET?

If you are volunteering to write the MailReader examples, go with the traditional approaches of both frameworks. After those are done, if you want to redo the Struts one to use Struts Dialogs, that would be valuable.
Don

QT - Michael Jouravlev wrote:
< replied-to message removed by QT >

QT - Ted Husted wrote:

>
>
< replied-to message removed by QT >

<< Or maybe I can rewrite Struts Dialogs for WebWork? >>

Yes, you might want to look into WebWork and see something like Struts Dialogs would be needed.

Trying to migrate the various MailReader examples, once we have migration tools, is an interesting idea. I do intend to try the tools against several of the Open Source Struts applications, such as the iBATIS JPetStore. XPlanner would be another likely suspect.

-Ted.

Edited by author 12-08-2006 05:02 AM
how to use tiles framework in struts2.0

examples for tiles-framework in struts2.0

This isn't a support forum.

To post questions about Struts, see <http://struts.apache.org/mail.html>;.