top bar
QuickTopic free message boards logo
Skip to Messages

TOPIC:

The WebWork Agenda

^     All messages    << 17-31  1-16 of 31        
16
Patrick Lightbody
11-15-2005
11:24 AM ET (US)
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 >
15
Sounds good
11-15-2005
09:36 AM ET (US)
I'm good with introducing the idea to more people...
14
Ted Husted
11-15-2005
06:34 AM ET (US)
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.
13
Ted HustedPerson was signed in when posted
11-12-2005
06:51 PM ET (US)
* 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.
12
Ted HustedPerson was signed in when posted
11-09-2005
07:28 AM ET (US)
>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.
11
Don Brown
11-07-2005
01:07 PM ET (US)
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
10
Ted HustedPerson was signed in when posted
11-07-2005
11:04 AM ET (US)
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.

####
9
Ted HustedPerson was signed in when posted
11-07-2005
10:45 AM ET (US)
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. |

####
8
Don Brown
11-06-2005
01:49 PM ET (US)
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 >
7
Ted HustedPerson was signed in when posted
11-06-2005
01:20 PM ET (US)
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.
6
Ted HustedPerson was signed in when posted
11-06-2005
01:16 PM ET (US)
Ooops

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

-T.
5
Ted HustedPerson was signed in when posted
11-06-2005
01:15 PM ET (US)
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@,

####
4
Don Brown
11-05-2005
05:47 AM ET (US)
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
3
Don
11-05-2005
05:20 AM ET (US)
Testing
2
Ted HustedPerson was signed in when posted
11-03-2005
07:44 AM ET (US)
(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.
1
Ted HustedPerson was signed in when posted
11-03-2005
06:23 AM ET (US)
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
^     All messages    << 17-31  1-16 of 31        

Print | RSS Views: 4482 (Unique: 1950 ) / Subscribers: 7 | What's this?