Some small changes would be needed to Codebehind, adding a few configuration parameters, which REST now sets by overwriting the base class. But we should do this anyway.
musachy On Wed, Jun 4, 2008 at 9:25 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote: > Here is yet another idea, this one assumes that multiple > UnknowHandler(s) can be stacked (which I am prototyping). If we modify > ControllerClasspathPackageProvider, so it delegates to an instance of > ClasspathPackageProvider instead of extending it, and using reflection > for the delegation of those few methods, we could have a nice setup: > > 1. Applications using Codebehind > No changes to Codebehind were done, they will continue to work > > 2.Applications using Codebehind + REST > REST ControllerClasspathPackageProvider will find Codebehind's > ClasspathPackageProvider in the classpath, and delegate to it using > reflection. These applications will continue to work without any > modification. > > 3. Applications using REST + Convention > REST ControllerClasspathPackageProvider won't find Codebehind's > ClasspathPackageProvider in the classpath so it won't do anything. > REST will work on top of Convention (this works fine). > > Plugins will be standalone, like they are now, and backward > compatibility will be kept. As a side effect, REST could be used with > XML configuration without Codebehind being in the classpath. I know > reflection is not a very elegant solution, but it would be temporary > until Codebehind is phased out, a few versions later. > > musachy > -- "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]
