struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Husted" <>
Subject Re: Poll: What part of a Struts will be the most important to support for migration?
Date Mon, 12 Jun 2006 23:31:09 GMT
On 6/12/06, Craig McClanahan <> wrote:
> There are also the cases where an existing app is going to be substantially
> re-implemented, and the natural question will be whether or not to upgrade
> the underlying framework to take advantage of new features.  If SAF2 doesn't
> even pay lip service to a migration story (which'd be pretty ironic of the
> lambasting that Shale got over wanting the "Struts" brand :-), then you're
> not giving the existing users much incentive to migrate to SAF2 versus any
> other framework.

:) First, I'm -1 on paying only "lip service" to anything. :)

My own viewpoint is that it's easy for *developers* to migrate to
SAF2. Most of us humans have a much longer life cycle than any given
application, so I see job one as helping developers migrate our
existing skill set.

It's also my direct experience that it is easy to migrate an SAF1
applciation to SAF2 by direct substitution of this SAF1 member with
that SAF2 member.  After I migrate another application or two, I could
see creating text-processing tools to help us do the same. (Not unlike
the tools people once wrote to convert HTML forms to SAF1 forms.)

I'm just asking if we're posing the right question. Do we want to
implement SAF1 members in SAF2 applications, or focus on mapping SAF1
members to SAF2 members?

There are some members and features we should bring forward, like
wildcards (already done). I think SAF2 DynaForms would be another
useful feature. But, my thought would be that the members we support
should be supported because they are generally useful, rather than


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message