On 6/12/06, Craig McClanahan <[EMAIL PROTECTED]> 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 legacies. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
