forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: [RT] A new Forrest implementation?
Date Thu, 17 Aug 2006 08:13:36 GMT
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

Mime
View raw message