The only conflict between codebehind and convention is on the UnknownHandler. If struts would support multiple UnknownHandler(s), like it supports multiple PackageProvider(s), we wouldn't have a problem at all, and they could be able to co-exist without knowing anything about each other. Given a request and multiple UnknownHandler, the first one that could return an action config would be used.
musachy On Fri, May 30, 2008 at 9:39 PM, Don Brown <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 7:21 AM, dusty <[EMAIL PROTECTED]> wrote: >> So lets do it and consolidate all of the configuration automation into >> Convention. We can get the new Convention and REST in 2.1.3-SNAPSHOT and >> then update the Codebehind page that its being absorbed into Convention. >> >> I say the new version of Convention doesn't have to support Codebehind if >> its going to hold back the Convention code base. > > I disagree, because if we just "switched" the rest plugin to use the > Convention plugin, we'd be screwing existing apps that use either the > Codebehind or REST plugin, of which I personally know several. At the > very least, the Conventions plugin should support Codebehind > applications via a separate conventions-legacy.jar project. We need > to be much better about not making backwards-incompatible changes for > our users, as one could argue that was Struts 1's greatest strength > and secret to much of its success. > > Don > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
