This isn't a support forum.

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

examples for tiles-framework in struts2.0

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

<< 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.

QT - Ted Husted wrote:

>
>
< replied-to message removed by QT >

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 >

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?

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.

Several committers are focussed on Shale with JSF right now, which is where the +0s come from. The committers already working on Action Framework seem to be looking forward to working with the WebWork
technology, which is about seven. The discussions were not in the form of a vote, so it wouldn't be appropriate to talk in terms of a tally.
-Ted.

On 11/21/05, QT - Sounds good <qtopic+33-KBfrHFUehSj@quicktopic.com> wrote: >


--
HTH, Ted.
http://www.husted.com/poe/
< replied-to message removed by QT >

What was the breakdown of +1 vs. +0? Is there active support, or just apathy?

Just to follow up:

All the Struts committers seem to be on board now, either +1 or +0. We had an 11th hour addition to the code last week, but that is resolved now, and we might be able to roll 1.3.0 today, which I'd like to do before announcing this.

-Ted.

Everything looks good in those documents.

I signed up to Confluence - sorry about the confusion. My username is plightbo.
On 11/17/05, QT - Ted Husted <qtopic+33-KBfrHFUehSj@quicktopic.com> wrote: >
< replied-to message removed by QT >

So far, four other Struts committers have commented on the proposal (plus Don and myself), and all the comments have been positive. There are another five committers who are tracking Struts 1.3.x who haven't chimed in yet.

Some of the other committers are focussed on Shale right now, and might not feel a need to chime in on this.

Before we go any farther, we should confirm that there won't be any showstoppers with the paperwork.

Patrick and Jason should review the Apache software grant and confirm that it would be something you could execute in relation to the WebWork codebase.

* http://apache.org/licenses/software-grant.txt

With other projects joining the ASF, there have been discussions on a public list authorizing an individual to execute the grant on behalf of the group. When the time comes, it might be helpful if Roger Oberg were part of that online discussion.

Please also confirm that you both have had a chance to review the ASF How it Works pages and the Apache Struts Charter.

* http://apache.org/foundation/how-it-works.html
* http://struts.apache.org/bylaws.html

All ASF committers must have a Contributor's License Agreement on file. Sometimes, there are conflicts with corporate IP agreements, so please be sure to review the CLA to see if there would be any problems when we get to that stage.

* http://apache.org/licenses/icla.txt

Patrick, Have you signed up for an account at

* http://opensource2.atlassian.com/confluenc...isplay/STRUTS2/Home

I'd like to give you karma to access the space, but I don't see an account that looks like it's yours. Right now, the space is invisible unless you are "on the list".

-Ted.

Ok, I submitted a copy of the proposal to the Struts committers.

Welcome to interesting times :)

-Ted.

Yes, QuickTopic is a mini-mailing list, so that people like us can discuss things like this :)

If you register with the wiki, Patrick, I'll give you karma to see the area. Right now, it's only visible to the four of us. As other people join us, I can add them to the list for the area, until we are ready to go public.

* http://opensource2.atlassian.com/confluenc...isplay/STRUTS2/Home

-Ted.

Yeah, sorry I haven't been more involved. To be quite honest, this QuickTopic stuff totally derailed me. Is this just a mini-mailing list or something? What about the wiki? Then when I saw a wiki entry on QT, I really lost it :)

Let's get more people involved. Jason and I are good enough from the WW side, so let's heap on the Struts folks. Genereally, I'm fine with any plan to move forward and would probably get more involved one we talked about the details of implementing the merger.

On 11/15/05, QT - Sounds good <qtopic+33-KBfrHFUehSj@quicktopic.com> wrote: >
< replied-to message removed by QT >

I'm good with introducing the idea to more people...

So, if I don't hear from anyone by this evening, I'll assume that we have a lazy consensus to invite to our discussion the other Struts committers (and WebWork committers, as appropriate).

-Ted.

* For Struts 1.3, we're subdividing the project into subprojects. We have been referring to the controller subproject as "Core", but a new name "Action" has been proposed. So far, it looks like "Struts Action Framework" will be adopted for the name of the controller subproject.

* I expect that we will roll 1.3.0 next week.

This might be a good time to invite the other committers to review the proposal document at the wiki space.

* http://opensource2.atlassian.com/confluenc...isplay/STRUTS2/Home

Note that I made some updates to the proposal this evening to use the Struts Action moniker and to add the FAQ we discussed. I also added a section to track and prior and next steps.

-Ted.

>Not sure how this would work. Superficially,
> combining chain and xwork in some way would
> be a great win, especially if we could get
> shale to use xwork somehow, as it would help
> to unify Struts. Thinking about it, however,
> I'm not sure that would be possible or
> technically desirable.

Interceptor does represent an interesting pattern. In OverDrive/Nexus [1], we do something similar in two places and implement the pattern differently both times.

In one place, we create a "request processor" using "pre-opt" and "post-opt" chains defined in the application's configuration. At runtime, a new Chain instance is created, and we append together the pre-opt Chain, target Command (action), and post-opt Chain, and then execute the dynamic Chain normally.

In another place, we have a "Processor" class with two main entry points, "ConvertInput" and "FormatOutput". One method is invoked by a Command in the "pre-opt" Chain, and the other by a Command in the "post-op" Chain. We do this since we find converting and formatting attributes tend to be tightly coupled.

Of course, both of these implementations differ from the WebWork Interceptors in that the "before" and "after" instances cannot not share private state within the execute method. All shared state is being passed through the Context.

An interesting aside is that in OverDrive/Nexus, we can wrap "actions" with optional services without additional components. Our "actions" are another instance of Command (or Chain). Of course, by using a Command for an "action", it is easy to inject optional services before or after the "action" Command, or combine "actions" together, with or without the optional services.

I do like the idea of Inceptors; I just wonder if there is way to achieve the same benefits with fewer parts.

-Ted.

QT - Ted Husted wrote:

> h2. Will development work on Struts 1.x and WebWork 1.x
> continue?

Both WebWork 2.x and WebWork 1.x are actively developed currently.
> h2. Will any API changes be made to the base WebWork codebase,
> such as to remove WebWork 1 legacy features?
>
> {{ Yes? }}

Perhaps, but on the guidance of Patrick and Jason. They might have some stuff they'd like to cleanup and this would be a good opportunity to do so.
> h2. Will Struts Ti utilize Inteceptors or Commons Chain?
>
> We may try to combine the two so that Interceptors are an
> extension of Commons Chain. Interceptors are great when you are
> trying to "wrap" another process. Chain is great when you are
> just trying to create fine-grained processes and combine them in
> different ways.
>
> {{ Thoughts on this? }}

Not sure how this would work. Superficially, combining chain and xwork in some way would be a great win, especially if we could get shale to use xwork somehow, as it would help to unify Struts. Thinking about it, however, I'm not sure that would be possible or technically desirable.

> h2. Will the WebWork tags be a separate subproject? What about
> Webwork IoC?

I think we should leave the tags. They aren't tied to a particular rendering technology and are very flexible. Our problem with the Struts tags is none of the developers used them, but I don't think that will be the case with these.
Also, WebWork IoC, I believe, has officially been deprecated in favor of Spring, so we could just remove that altogether.

Don

>
>
>
> h2. Will Spring be used as an enabling technology?
>
> Yes.
>
> h2. Will Struts Ti be compatible with Spring MVC? Other
> frameworks?
>
> Our primary target is Struts 1.3 and WebWork 2.2, but we'd like
> to support great ideas from other frameworks too.
>
> ####
> _________________________________________________________________
> To unsubscribe: http://www.quicktopic.com/33/X/KBfrHFUehSj
> Start your own topic in 20 seconds: http://www.quicktopic.com |QT

My first whack:

----

h2. Why not do this through Open Symphony rather than Apache and make this WW3?

Benefits of doing this as an Apache project include

* The Apache Software Foundation is a not-for-profit corporation that insulates the volunteers from liablitity.

* The Foundation provides an assurance to the user community that the software will remain available under the business-friendly Apache License.

* Many teams are already authorized to use Apache Struts. Obtaining authorization to use another product can be a lengthy process.

h2. Will related OpenSymphony projects, like SiteMesh and XWork, merge with Struts too?

Probably not. Apache Struts already uses other products internally, and we can use SiteMesh and XWork too.

h2. Is this a proposal for "Struts 2.x"?

Not yet. If there is a clear and simple migration path from Struts 1.x to Struts Ti, then the Struts PMC may want to consider calling the product Struts Core 2.x, but it's too soon to say.

h2. Will development work on Struts 1.x and WebWork 1.x continue?

Yes, we expect that it will. The Struts and WebWork committers are also Struits and WebWork users, and we would want to keep both products up to date. It's also possible that we may help teams migrate to Ti step-by-step through a series of changes to the existing codebases.

h2. Will any API changes be made to the base WebWork codebase, such as to remove WebWork 1 legacy features?

{{ Yes? }}

h2. Will Struts Ti utilize Inteceptors or Commons Chain?

We may try to combine the two so that Interceptors are an extension of Commons Chain. Interceptors are great when you are trying to "wrap" another process. Chain is great when you are just trying to create fine-grained processes and combine them in different ways.

{{ Thoughts on this? }}

h2. Will Struts Ti be compatible with Struts 1.3? WebWork 2.2?

Yes, we hope to run most existing applications out of the box, and provide a clear migration path that any existing application could follow.

h2. Will the WebWork tags be a separate subproject? What about Webwork IoC?

<< Yes? Are we going to include WebWork IoC? >>

h2. Will Spring be used as an enabling technology?

Yes.

h2. Will Struts Ti be compatible with Spring MVC? Other frameworks?

Our primary target is Struts 1.3 and WebWork 2.2, but we'd like to support great ideas from other frameworks too.

####

On 11/6/05, Patrick Lightbody <plightbo@gmail.com> wrote:
> Sorry about the delay guys - i'm on the QuickTopic list now.
> What's next? :)

Here's my suggestion:

Next Steps

|-1 | Subscribe to the QuickTopic. |
| 0 | Create an account on the [Confluence site|<http://opensource.atlassian.com/confluence/oss/x/kQY]. |
| 1 | Finalize the "WebWork Agenda" proposal. |
| 2 | Invite the rest of the Struts, WebWork, and Beehive (?) committers to the table. |
| 3 | Update the initial proposal(s) as needed. |
| 4 | Draft an Incubator proposal to manage donation of the WW2 codebase. |
| 5 | Launch. |


Extensions

||1a ||Consider drafting a "mirror" proposal targeted for the WebWork development community. |


||1b ||Add a FAQ to the proposal(s). |
|| ||The proposal should include a FAQ so that we have ready answers to the obvious questions (talking points). |
| .1 | Draft some likely questions. |

* Why not do this through Open Symphony rather than Apache and make this WW3?

* Will related OpenSymphony projects, like SiteMesh and XWork, merge with Struts too?

* Is this a proposal for "Struts 2.x"?

* Will development work on Struts 1.x and WebWork 1.x continue?

* Will any API changes be made to the base WebWork codebase, such as to remove WebWork 1 legacy features?

* Will Struts Ti utilize Inteceptors or Commons Chain?

* Will Struts Ti be compatible with Struts 1.3? WebWork 2.2?

* Will the WebWork tags be a separate subproject? What about Webwork IoC?

* Will Spring be used as an enabling technology?

* Will Struts Ti be compatible with Spring MVC? Other frameworks?

| .2 |Post our answers to the questions on the QuickTopic and combine our responses on the wiki. |


||3a ||Add RoadMap to the proposal. |
| .1 | Once we have a consensus with the core community, we should draw up a clear roadmap of what we expect to do with "Ti

Phase 1", and make the roadmap part of the proposal.|


||3b ||Consider writing system Use Cases for Struts Classic, WebWork 2.x, and Ti to support the roadmap. |

####

I've brought it up with him privately already, since he and I worked together a lot on Ti. He is very enthusiastic, and wants to present it to Beehive as soon he can. I'll ask him to subscribe to the topic.
Don

QT - Ted Husted wrote:
< replied-to message removed by QT >

Since, we mention Rich Feit in the proposal, do you think we should invite him to review the draft proposal, and get his feedback on our roadmap?

-T.

Ooops

/s/*/* http://opensource.atlassian.com/confluence/oss/x/kQY

-T.

Right back at 'cha:

*

To access the site, you'll have to subscribe and then let me know, so I can grant karma. Don already had an account, so he's already in. (This is the same place where the JWAG site lives, and where the Ti wiki could live, so you should have an account anyway!).

Here's a patch-like summary of revision 3 changes:

- they are very interested in merging WebWork with Struts.
+ they are very interested in merging WebWork with Struts.
+ An archive of our discussions is available as a Quick Topic thread: <http://www.quicktopic.com/33/H/KBfrHFUehSj/p16.1#QTmsg4>;.

- use WebWork as the core of Struts 2.0.
+ use WebWork as the basis of Struts Core 2.0.

- sandbox project is redesigned
+ sandbox project be redesigned

- Core - WebWork + Commons Chain integration + Struts 1.x compatibility Page Flow - Beehive's Page Flow + simplified annotations + quick development mode
+ Ti phase 1 = WebWork + Commons Chain integration + Struts 1.x compatibility
+ Ti phase 2 = phase 1 + Beehive's Page Flow + simplified annotations + quick development mode

- Once we feel Core has matured and can provide a high degree of Struts 1.x backward-compatibility, we plan to propose the component to be accepted as Struts Core 2.0.
+ When the Ti phase 1 has coalesced and is providing a high degree of Struts 1.x compatibility, our intention would be to propose Ti as a Struts Core 2.x candidate. Until that time, we would continue to consider Ti a "next generation" proposal and, pending a decison by the PMC, avoid attaching the 2.x label to Ti.

- community feels it would be better suited.
+ PMC feels it would be better suited.
+
+ As we work on Struts Ti, we would also expect that work would continue on Struts Core 1.x, perhaps including feature changes that would bring the codebases even closer together.

- We would bring the WebWork codebase
+ To get started, we could bring the WebWork 2.2 codebase

- get Ti Core ready for a migration vote.
+ get Ti Core ready for an acceptance vote.

- Beehive's Page Flow project to merge with Struts officially alongside WebWork.

+ Beehive's Page Flow subproject to officially merge with Struts alongside WebWork.

- PS - If we do decide to go forward, we should post a summary of
this thread to dev,
+ PS - If we do decidee to go forward, we could post a link to the Quick Topic on dev@,

####

My cut:

Merger with WebWork
Ted, Don, Patrick, and Jason

Between the Clarity hubbub [1] and the Java Web Alignment brouhaha [2], it came up that WebWork would like to merge with another
framework. Ted and Don followed up with the two core WebWork developers, Patrick Lightbody and Jason Carreira. As it turns out, they are very interested in merging WebWork with Struts.

As some of you know, the underlying idea behind Ti was to use WebWork as the core of Struts 2.0. Conceptually, WebWork and Struts Core are very similar. We've often said, without embarrassment, that WebWork does many things better than Struts Core. Meanwhile, WebWork has the ability to provide a layer of almost full backwards-compatibility for Struts Core, and we have already demonstrated we can integrate
Beehive's (very cool) Page Flow with WebWork.

PROPOSAL: Bring WebWork into Struts through Struts Ti

We propose the Struts Ti sandbox project is redesigned to contain the following components:

Core - WebWork + Commons Chain integration + Struts 1.x compatibility Page Flow - Beehive's Page Flow + simplified annotations + quick development mode

Once we feel Core has matured and can provide a high degree of Struts 1.x backward-compatibility, we plan to propose the component to be accepted as Struts Core 2.0. When Page Flow matures, it may be proposed to be merged with Struts Core 2.0 or migrated as a new subproject depending on where the community feels it would be better suited.
We would bring the WebWork codebase into the Foundation through the Incubator. As part of the proposal to the Incubator, we could elect Patrick and Jason as committers, so that they could help us get Ti Core ready for a migration vote.

A quick note on Page Flow - thus far, Beehive's Page Flow has been migrated to Struts Ti through the feverish work of Rich Feit, however, a better approach might be to invite Beehive's Page Flow project to merge with Struts officially along side WebWork.

We feel this presents a great opportunity to bring both alignment and relevance to the Struts project as a whole. We hope even Shale will find aspects of Ti Core to utilize, once again placing every Struts subproject on top of Struts Core.

By a happy coincidence, WebWork in Action is out, and, if there were interest, we could talk to Manning Publications about getting
complimentary copies for the committers.

Thoughts?

-Ted et. al.

PS - If we do decide to go forward, we should post a summary of this thread to dev, along with the Incubator proposal. We could then vote on the Incubator proposal on the dev list, to make the decision both official and transparent.

[1] Clarity -
http://opensource2.atlassian.com/confluenc...display/WAG/Clarity
[2] Java Web Alignment Group -
http://opensource2.atlassian.com/confluence/oss/display/WAG/Home

Testing

(Sorry about the length, but this should be my one-and-only post for the day.)

OK, from what I can gather, it sounds like we can agree on a proposal that would amend Ti to include two distinct phases

* Phase 1: Bringing the WebWork 2 code base into Ti and build a compatability layer between Struts 1.3.x and WebWork 2, along with a set of migration tools.

* Phase 2: Finish building the other features outlined in the initial Ti proposal.

At the top of the thread, Patrick mentioned "WebWork 3". Were there any concrete plans for a WebWork 3? If there are any plans, do they have any common ground with the initial Ti proposal?

Meanwhile, it sounds like the next step is a small proof-of-concept application, like a two-page login application, that would demonstrate what we are talking about, without doing any more of the work than is strictly necessary.

I've started some Use Cases for the MailReader example application, and it might help to start by doing a set of these for the proof-of-concept application.

* http://opensource2.atlassian.com/confluenc...ay/STRUTS/Use+Cases

* http://opensource2.atlassian.com/confluenc...y/STRUTS/MailReader

* http://opensource2.atlassian.com/confluenc...RUTS/Struts+Classic

If there were interest, having a set of Use Cases for both Struts Classic and WebWork 2 might help us work through some of the compatibility and feature overlap issues. [Though, I might need a copy of WebWork in Action to help with that set :)]

After all, regardless of whether interceptors are better than Chain, or whether SiteMesh is better than Tiles, we still have to confront the tyranny of the installed base. Struts Core 1.3.x utilizes Chain as a configuration tool and encourages people to use it as a business facade. Even though Struts Core 1.3.x is unreleased, it is already out there, and some of us are using it in the production.

The reason Shale is not Struts 2.x is because there was so much concern about doing things better, that we ended up with no easy way to pour our old wine into the new bottle. Many of us can't afford to recode the many large and mature Struts applications now in production. There has to be a clear and simple way to get there from here.

One way to "get there from here" is backward compatibility. Another way is migration tools. As Don mentioned, we can migrate assets like XML configuration files using XLST. In the end, we will probably need to use both techniques. We might also want to consider whether we can provide a migration path from Spring MVC, perhaps as part of Phase 2.

Aside from core support for a feature, we can also do things like provide bridge classes. When we migrated the Action signature between Struts 1.0 and Struts 1.1, we changed the old signature so that it would use the new, and deprecated the old. In Struts 1.2, we removed the old. Once we have a clear end in mind, we could start a round of deprecations and removals in the Struts 1.x series and march it toward the new codebase, being careful that "no app is left behind". :)

-Ted.

INITIAL MESSAGE:

----

On 10/28/05, Patrick Lightbody <plightbo@gmail.com> wrote:
> On that note, here's my agenda: I now only care about reducing the
> amount of work needed to keep the WebWork community happy. This
> includes the possibility of dissolving the project and joining forces
> with another project (or vice versa).

Patrick,

The Struts community has always admired WebWork. Speaking only for
myself, I would be very open to the idea of merging OS WebWork with
Apache Struts.

We've often said that "WebWork has it right" when it comes to things
like ActionForm and independency from the HTTP API. Once upon a time,
my friend Eric Hatcher accused Struts of being WebWork wannabes. I
think there's some truth to that.

I've copied Don Brown into this message, since when he sees your post,
he's likely to have the same thought :)

If you or Jason would like to discuss this further, I'm at your
disposal. My contact stuff is here:

* http://husted.wush.net/docs/display/~ted

As you see, my own work is dependant on WebWork, via Confluence :)

-Ted.

----

NOTE: For the rest of the pre-QuickTopic thread, please see
http://people.apache.org/~husted/WebWorkAgenda.pdf