forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [RT] A new Forrest implementation?
Date Thu, 17 Aug 2006 21:24:59 GMT
David Crossley wrote:
> 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.


> 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.


Certainly, if Cocoon had a Java component that enables it to be embedded 
within a Java application then this would be possible. In fact, this is 
a really good option. It gives a really low entry point into Forrest, 
but allows those with Cocoon skills to leverage its undoubted power.

(whatever happened to the Cocoon Bean?)

> 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?

[snipped stuff about better samples in documentation]

I certainly agree better documentation would help. However, it doesn't 
remove the complexity, it simply gives more tools to help the user get 
over that complexity.

Maurice says in another mail in this thread:

"So, do we feel that Cocoon skills should be a prerequisite for 
non-trivial usage of Forrest?"

For me the answer is no. There are far more people with Java skills than 
there are with Cocoon skills, which has a prerequisite of Java skills 
for most non-trivial use cases.

However, if we can find a way of doing what David suggests, that is 
enabling those with Cocoon skills to leverage them, whilst allowing 
those with Java skills to go that path, and those with skill X to use 
that, then this has to be a great option.


>>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.

Yes, an input plugin converts from one format to the internal format.

There are occasions when it is desirable (although never necessary) to 
have two transformations as I have done with the MS Office plugin 
(office -> OOo -> XDoc). This is not currently supported (although there 
are hacks) in Forrest because of the limitations of the sitemap mounting 
system (real blocks will solve this though).

In my alternative approach where an input plugin is a java object you 
simply need to extend the first input plugin. So, in this case it really 
is a single plugin.


View raw message