On Sat, Nov 29, 2008 at 01:49:27AM +0000, Ross Gardler wrote: > > On 29 Nov 2008, at 00:56, Brian M Dube wrote: > >> I'd like to spend some time on a proof of concept version of Forrest >> without Cocoon, whether that's whiteboard/forrest2 or a new >> approach. One of the requirements, or at least functional tests, that >> has already been mentioned with respect to forrest2 is that the seed >> site must function correctly. I think this implies that current style >> plugins need to be supported. > > That really depends on your use case. The majority of work in the > plugins is the XSLT, so reuse of part of the plugins would probably be > acceptable. However, those plugins are based on XDoc and we have been > intending to go to XHTML2 for a very long time and Forrest2 would be the > sensible time to do that. > > So, I'd say there is no need for it to be compatible with existing > plugins. I would say that it should be compatible with the important > part of Forrest. That is, existing sites should work without > modification - or a tool be provided for conversion.
I don't think it would take much to modify the plugins that provide only XSLT. The plugins that use Java to do their work will involve more design decisions to remove their dependence on Cocoon, Avalon, Excalibur, etc. It would be nice to have Spring wire in and expose the plugins. >> To support current plugins requires sitemap and locationmap >> implementations that don't depend on Cocoon. > > My original motivation for the Forrest2 experiments was to remove the > complexity of the sitemap (an expressive language for web apps, not > applicable to a publishing framework) and further enhance the ideas in > the locationmap (decoupling of source and target data). > > For me Forrest 2 should not be constrained by Forrest 1. > >> It looks difficult, but >> not impossible, to extract sitemap support from the Cocoon >> source. Is this the way to go? > > Not for what I did with Forrest2 in whiteboard. I can't answer for your > own use case. > > Speaking personally, if your work went the sitemap route I would > probably not be engaged by it. That's not to say it is a bad idea - just > that if it doesn't solve the configuration complexities of the current > system I'm not sure what utility it would have for me. I'd like to avoid carrying over sitemap support. I had been thinking it was necessary to keep existing sites from breaking, but a conversion tool would solve that problem. It's complex, it's for web apps, it can be factored out. > However, have you looked at the Cocoon 3 work? From what (little) I know > of this it is a simplified Cocoon. I looked at it briefly and it does look simplified. I didn't stay long after I saw that it was a Maven project. > My motivations can be found in the archives, > e.g. http://markmail.org/message/dxy3qrsw4jyw26rd Thank you. I knew something like this was out there but my initial search didn't turn it up. Nearly everything I've been thinking is covered in that post. >> Is there community interest to move away from Cocoon? > > My Forrest2 proposal was never about moving away from Cocoon. It was > about removing the need for a monolithic web framework for creating an > XML publishing framework. My Forrest 2 design was all about allowing > people who need to leverage Cocoon (or any other framework) in a Forrest > content object - but not forcing them to do so. Yes, I agree. It would be great to be able to drop in Cocoon or whatever you need, but not have it as the base when all you need is Forrest. Brian
