Jorg Heymans wrote:
> Recently there were 2 requests on the users list about accessing the
> current pipeline structure.
<snip/>
> Having this extra metadata would allow for components that
> can produce
> different output depending on how they are used in a pipeline
> (but this
> probably breaks a few cocoon design rules right?).
It certainly creates the _potential_ for components to be horribly tangled up with the
pipelines that contain them.
<snip/>
> Thoughts? Is this difficult to implement? A 2.2 feature perhaps?
I don't know about the use cases presented on the user list, but I know another use
case is for debugging and maintenance people to have direct access _from a
Cocoon-produced resource_ to the pieces of the pipeline that produced it. In this
scenario the final output contains a bunch of hyperlinks to the resources (content,
transforms, stylesheets, etc) which can be used to get quick access to edit one of
these sources.
As an experiment I implemented this for some pipelines using XML processing
instructions. Each pipeline component adds a PI to the SAX stream to identify itself
(a signature), and at the end a transformer can convert them into HTML <link> elements
or similar. NB this is totally different to (the inverse of) the use of PIs embedded
into a source XML file to specify an XSL transformation. It wasn't very convenient to
add each PI at each stage, but it seemed to me that the pipeline processor could
certainly maintain this metadata more easily, and make it available to components when
needed. Perhaps a special pipeline processor could keep track of the pipeline, and use
a special transformer which is "pipeline aware" ("InsertPipelineMetadataTransformer")
to insert this metadata into the pipeline only when needed.
Cheers
Con
