Ross Gardler wrote: > This is a Random Thought. The ideas contained within are not fully > developed and are bound to have lots of holes. The idea is to promote > healthy discussion, so please, everyone, dive in and discuss.
I don't know where to begin to answer this. One way is with more random thoughts. In such RT threads we have the freedom to throw wacky ideas into the mix. Intertwine that with our own use-cases, etc. and as long as we all help to calmly discuss, then a strong combined solution should emerge. I do agree that we could build a better framework. Perhaps we currently try to use Cocoon for too much. Perhaps Cocoon should not be the controller, i.e. Forrest should control the whole process and decide which input plugins and which output plugin to use. Perhaps Forrest should provide some ways to generate the internal format from the various sources. Perhaps Cocoon could be an optional way to handle those stages, e.g. if i prefer Cocoon then it should be simple for me to add it and use its sitemap and generators and transformers to do the input processing in my input plugins. Another way to answer this RT might be to look at the issues from other points-of-view, e.g. What is it that causes people to baulk at getting more involved with Cocoon? Perhaps we don't provide enough encouragement by leading the way, e.g. more sitemap examples via howto docs and seed sites, describe complex use cases and how to solve them with Forrest/Cocoon. I reckon that we have not given Cocoon a fair go. We need to tidy up our core and plugin sitemaps and explain how they operate. This will get people enthusiatic when they see the beauty. Then they are encouraged to help with Cocoon development, and ease our collective way. It is a long RT mail so i have just tried to respond to a few parts. Will try again later. > The Problem > =========== > > Forrest is built on Cocoon, a web application framework, but "all" it > does is XML publishing. This means we have a monolithic web application > framework that is doing nothing more than managing a processing pipeline > and doing XSLT transformations. Interesting: Cocoon started life as an "XML publishing framework". Then people thought that that was too limiting, so it changed its description to be a "web development application framework". That got all the buzzwords. The term "web" is superfluous. Monolithic? We use the Cocoon core and then only the blocks that we need. People can add more Cocoon blocks to their own Forrest. In particular, we do not include the Cforms Block which is Cocoon's interactive web forms stuff. > Let me try to illustrate... > > What Forrest Does > ================= > > Input -> Input Processing -> Internal Format -> Output Processing -> > Output Format > > To do this we need to: > > - locate the source document > - determine the format of the input document > - decide which input plugin to use > - generate the internal format using the input plugin > - decide what output plugin we need > - generate the output format using the output plugin > > Lets look at each of these in turn > > Locate the source document > -------------------------- > > To do this we use the locationmap, this is Forrest technology. This is too simplistic. I have various applications where the "input" is the result of other pipelines, especially aggregation of other pipelines. There is not just a single source document. I love the connectedness and re-usability of Cocoon's pipelines. Or perhaps you already mean that it could be a complex source, cached or dynamic, that is located. I get the feeling that we are losing some multi-dimensional capability that is provided by the Cocoon sitemap. > Determine the Format of the Input Document > ------------------------------------------ > > This is either done by: > > a) guessing the source format based on the file extension > b) reading the source format from the document itself (SourceTypeResolver) > > a) is a "standard" way of doing things and b) is Forrest technology Good. Hooray for b. > Decide which input plugin to use > --------------------------------- > > This is done by resolving the processing request via the Cocoon sitemap. > But why? > > Each input type should only be processed by a single input plugin, there > should be no need for complex pipeline semantics to discover which > plugin to apply to a document, all we should need to do is look up the > type of document in a plugins table. Sounds better. I have not thought this through properly, but i wonder if it is always just one input plugin. > Generate the internal document > ------------------------------ > > This is typically done by an XSLT transformation, but may be done by > calling the services of a third party library (i.e. chaperon) > > Either of these actions are easy to achieve through simple Java code, > however, we currently "benefit" from the fact that Cocoon transformers > are already implemented to do these transformations for us. It is true > that Cocoon provides a load of such transformers for us, but how many do > we actually use? How complex are they to write as a POJO? How complex > are they to write as a Cocoon transformer. > > My point is that in this instance the Cocoon complexities are making it > harder for developers to get involved with Forrest and so they simply > don't get involved. The suite of default Cocoon Generators is important. They supply many of our needs. For my applications, some of which are quite complex, the default set of Generators and Transformers, combined with the power of the sitemap, are all that i need. If Forrest developers need more than this, and are attempting to create their own Generators/Transformers and are stuck, then we should be hearing more questions to our mailing list. I wonder if people ever even get to step one, and start to explore using Cocoon's existing offerings. I reckon that we do not supply enough sitemap examples and so are doing ourselves a dis-service. ------ That is as far as i managed to get to in this sitting. Thanks for looking into these key topics. -David
