> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] > > > However I don't think that there needs to be any serious backwards > > compatability changes to enable it. > > I'm pretty sure that nobody will object changes in the cocoon > internals > if there is a way to provide (even a minimal) back > compatibility for the > cocoon 2.x components that users might have written for themselves. > > I repeat: nobody is against having to change the cocoon internals to > follow what the Avalon community decided (we don't want to be > stuck on a > framework that is considered obsolete by its own community) > but all of > us are *seriously* concerned about the impact of these changes to the > current user community. > > As you said in another post, a migration path must be provided.
One very effective pattern that Cocoon can use to provide backward compatibility with altered component interfaces is a "facade" AKA Adapter pattern in OO speak. Essentially you have one implementation of the new component interface that does nothing but call existing components from a prior version. This allows you to play with the interface until you have something you like. Once you are satisfied, you can begin the earnest migration of all the old components. That is one level that anyone can use in any component framework. All the configuration files and all the other meta information will be supported with tools to migrate and dynamically load/use at runtime. Essentially Cocoon should have a much easier time of migration than 1.x to 2.x. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
