Jason Carreira wrote:
I have a couple of comments to make about this.
First of all, presumably the whole motivation of this
merger is that
you could unite your energies on a common framework.
If there is still
ongoing work on 2 different frameworks, it kind of
belies the whole
point of the
Ted Husted wrote:
On 5/5/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
The current versioning/naming system will force them, because it does
not make distinction between Classic and WebWork. Most users and/or
their managers know that higher version number means newer and better
product. Which
Let's not exaggerate the impact of the API on user
code though...
Users record validation errors a little differently;
you should be
able to port existing WW2 code pretty easily with
some clever
refactorings (which we will document when the time
comes).
And we're trying to simplify
I have a couple of comments to make about this.
First of all, presumably the whole motivation of this
merger is that
you could unite your energies on a common framework.
If there is still
ongoing work on 2 different frameworks, it kind of
belies the whole
point of the merger,
On 5/6/06, Bob Lee [EMAIL PROTECTED] wrote:
The new API should be simpler, cleaner, better separated from the
implementation, more intuitive, and better organized. If you
understand WW2, you'll have no problem understanding the new API. If
you haven't learned WW2 yet, it will be easier to learn
I am a bit surprised that this was not all pretty well worked out in detail
before the merger. Why not first take the time to see what will need to be
done and what the result will look like before deciding to do it? That
should not be a daunting task. A list of what the result will take and
Don't worry, David. We're just talking about cleaning up the API and
making your code a little cleaner. It's fundamentally the same
framework with the same philosophies.
Bob
On 5/5/06, David Evans [EMAIL PROTECTED] wrote:
I am a struts user who has recently began programming in webwork, to get
Don't worry, David. We're just talking about cleaning
up the API and
making your code a little cleaner. It's fundamentally
the same
framework with the same philosophies.
Bob
Maybe the same philosophies, but the API you laid out is very different for
users of the framework...
On 5/6/06, Jason Carreira [EMAIL PROTECTED] wrote:
Maybe the same philosophies, but the API you laid out is very different for
users of the framework...
Let's not exaggerate the impact of the API on user code though...
Users record validation errors a little differently; you should be
able
Ok, let's just make this an official proposal and focus all of this discussion:
I propose that the architecture plan for Struts Action 2.0 includes the
following:
1. A re-design of the API to simplify the framework the users see
2. Backwards-compatibility support for WebWork 2 and Struts 1.x
On 5/5/06, Don Brown [EMAIL PROTECTED] wrote:
Ok, let's just make this an official proposal and focus all of this discussion:
I propose that the architecture plan for Struts Action 2.0 includes the
following:
1. A re-design of the API to simplify the framework the users see
2.
Michael Jouravlev wrote:
SAF1 could have future if migration to SAF2 were impossible or too
complicated. But according to your plan, migration from SAF1 to SAF2
should take days. What is the point of keeping Action 1.x to be
developed actively?
I am not objecting, I am just asking. Trying to
Just as some people continue to use WebWork 1.xx (JIRA) I imagine
people will continue to use SAF1 regardless of how easy the migration
path is.
I always assume it would take a day or two to convert existing WW code
to SAF2 so at the end of the day just picking a direction is progress.
:)
I'm OK with this, from an end user perspective certainly, and from a
(sort of I guess) framework developer as well.
However, you raise an interesting point in my mind...
Struts Action 1.x will continue to be developed actively
Ok... I personally like that. However, why wouldn't it also be
Subject: [action][Proposal] Architecture plan for Struts Action 2.0
Ok, let's just make this an official proposal and focus all of this discussion:
I propose that the architecture plan for Struts Action 2.0 includes the
following:
1. A re-design of the API to simplify the framework the users see
If the WebWork committers make the decision to continue developing WebWork 2.x,
they are entirely free to do so. If Struts Action 1 committers decide to
continue developing Action 1, they are also free to do so. However, if WebWork
2 developers decide to stop work and focus completely on
to a end developer. That goal will drive any changes.
Don
Thanks,
Gabe
- Original Message
From: Don Brown [EMAIL PROTECTED]
To: Struts Developers List dev@struts.apache.org
Sent: Friday, May 5, 2006 4:04:35 PM
Subject: [action][Proposal] Architecture plan for Struts Action 2.0
Ok
Don Brown wrote:
The purpose of this merger is not to create yet another framework or
kill off competition, but to start collaborating as framework developers
for the greater good of the general community. By focusing on who can
do what or why can't a project release something, you are
: Friday, May 5, 2006 4:36:13 PM
Subject: Re: [action][Proposal] Architecture plan for Struts Action 2.0
Gabe wrote:
Where XWork is in this proposal is a little vague. Would this proposal break
the traditional division of roles between XWork and Webwork (Where SAF 2 is
where webwork was)? If so
Gabe wrote:
I am all for simplifying the API to the end developer, but I wonder if those
changes could be pushed to XWork in the form of an XWork 2.0, with, of course,
the Web specific portions being added to SAF 2.
Agreed, and with my XWork developer hat on, XWork 2.0 will be required to
This sounds fine to me, Don.
I'd suggest annexing this to the original Ti proposal as a clarification.
-Ted.
On 5/5/06, Don Brown [EMAIL PROTECTED] wrote:
Ok, let's just make this an official proposal and focus all of this discussion:
I propose that the architecture plan for Struts Action
On 5/5/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
But that's precisely my point... isn't the best way to combine the
talents to take the cuffs off, so to speak, and not worry about
backwards-compatibility?
Yes, and this is why the Ti proposal talks about two phases.
In the first phase,
On 5/5/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
If the existing branches can continue to develop, then the community is not
hurt by breaking compatibility, they are actually HELPED because the
merger yields a much greater value in the end, and people will probably
want to migrate despite
Michael Jouravlev wrote:
On 5/5/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
If the existing branches can continue to develop, then the community
is not
hurt by breaking compatibility, they are actually HELPED because the
merger yields a much greater value in the end, and people will
On 5/5/06, Phil Zoio [EMAIL PROTECTED] wrote:
Michael Jouravlev wrote:
On 5/5/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
If the existing branches can continue to develop, then the community
is not
hurt by breaking compatibility, they are actually HELPED because the
merger yields a
On 5/5/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
The current versioning/naming system will force them, because it does
not make distinction between Classic and WebWork. Most users and/or
their managers know that higher version number means newer and better
product. Which is why I preferred
I am a struts user who has recently began programming in webwork, to get
a head start for action 2. Having just spent many hours researching,
reading about and experimenting with webwork, I personally hope that you
start with a version of action 2 that resembles webwork pretty closely.
I wonder
27 matches
Mail list logo
