struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Husted" <hus...@apache.org>
Subject Re: [s2] Goal - no experimental code in core for 2.1
Date Tue, 09 Oct 2007 14:14:43 GMT
If we want stable conventions, then we should try to exercise the
conventions against more applications, to be sure we're covering the
core use cases. I know some of us are trying these with our own
applications, but we should also try them with more example
applications that we can all review.

In-house, we have MailReader and Showcase. I've a preliminary
implementation of the MailReader up that works (at least in a single
namespace). Perhaps we should move the work-in-progress from
GoogleCode to the sandbox, or even to SmartURLs as its 2.0.x example.

Another likely candidate would be a "Petstore Zero". I have a Petstore
site started on Google Code, if anyone would like to join in. A JPA
implementation might be especially helpful.

If we had these three applications working well, with no XML actions,
bare minimum annotations, and sensible validation, then there would be
a good chance that we would be covering enough of the basis to keep
the conventions stable moving forward.

Moving forward, I'm willing to consider the conventions a core
feature, even if we ship them as a plugin. Meaning that if we do want
to break backwardly compatibility to introduce a different set of
standard conventions, I'd vote to roll the major version number, for
that reason alone.

Of course, before we get to the point of rolling a version number, we
would have had been able to try the conventions in the form of an
alternate plugin for some time. As mentioned, distributing features in
a plugin format makes it much easier to throughly test new things
ourselves, before we make changes to the standard distribution.

(And encore kudos to Don for bringing us the plugin feature and
initial codebehind plugin that have made all this possible!)

-Ted.

On 10/8/07, Don Brown <mrdon@twdata.org> wrote:
> On 10/9/07, Ted Husted <husted@apache.org> wrote:
> > So, in the same way that WebWork 2 became Struts 2, SmartURLs 2.1 will
> > become CodeBehind 2.1.
>
> I'm fine with this on one condition: 100% backwards compatibility.
> Backwards compatibility is so crucial for convention-based designs,
> because there is no clear feedback to the user that changes have been
> made.
>
> If you change an API, you probably deprecate the old methods, which
> gives immediate feedback to the user that something has changed, and
> they can usually view the javadocs on the deprecated method to see the
> suggested fix.  If you just remove a method, the compiler will
> immediately tell the user something has changed. With a
> convention-based system, things just stop working and the user has no
> immediate reason why or how to fix it.
>
> This is one reason I like the idea of moving the zero conf out to a
> plugin is it is easier to develop new convention-based systems, while
> allowing legacy apps to continue working using the older system.
>
> Don

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message