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
>
> 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 mer
> 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 s
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. Whic
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 wh
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
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
> 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...
---
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 ge
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 ho
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
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
>> me
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, 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 despit
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,
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 2
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
sup
iday, 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
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 missing
to a end developer. That goal will drive any changes.
Don
Thanks,
Gabe
- Original Message
From: Don Brown <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Friday, May 5, 2006 4:04:35 PM
Subject: [action][Proposal] Architecture plan for Struts Action 2.0
Ok, let'
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 Strut
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
2
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 s
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.
:)
Cheers
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
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. Backwards-
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
27 matches
Mail list logo