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.
Absolutely.
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.
Interesting...
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.
Ross
