Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: accessing the pipeline structure
Date: Fri, 10 Sep 2004 14:28:29 +1200
Message-ID: <802926B6AB8533408C33ADBCA3EE5C2A138C36@coso.staff.vuw.ac.nz>
Thread-Topic: accessing the pipeline structure
Thread-Index: AcSWfg/jpKmdU13FRK6zz7tNpf11JwAXReJg
From: "Conal Tuohy" <Conal.Tuohy@vuw.ac.nz>
To: <dev@cocoon.apache.org>

Jorg Heymans wrote:

> Recently there were 2 requests on the users list about accessing the=20
> current pipeline structure.

<snip/>

> Having this extra metadata would allow for components that=20
> can produce=20
> different output depending on how they are used in a pipeline=20
> (but this=20
> probably breaks a few cocoon design rules right?).=20

It certainly creates the _potential_ for components to be horribly =
tangled up with the pipelines that contain them.=20

<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