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]
