Initially I figured we could pull things from zero-conf, code-behind and
SmartURLs out into the plugin and then work from there. But now I'm
thinking that deprecating all the old code-behind, zero-conf and
SmartURLs stuff were it is at and not supporting it any longer might be
best. Most of this stuff is working as is and allowing folks to use
those features from the current locations shouldn't impact new
development going forward. Therefore, leaving it where it is at should
be fine and then starting a new plugin called convention or something
based on the Struts and SmartURLs code bases in a brand new package.
OR we could do this:
1. Pull out the existing SmartURLs, zero-conf and codebehind into a new
plugin called convention or something.
2. Deprecate all of it but ensure it works seamlessly.
3. Create new annotations, classes, etc in a new package
(org.apache.struts2.plugin.convention) based off the existing code.
4. Update things as needed to get it all working with no mods or
application breakage.
5. Plan removal dates for the old code. I'd say 2.2 would be fine.
Thoughts?
-bp
Ted Husted wrote:
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 <[EMAIL PROTECTED]> wrote:
On 10/9/07, Ted Husted <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
