Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Subject: Re: Chaining plguins (was Re: What does "XHTML2 as an
	internal	document format" mean?)
From: Thorsten Scherler <thorsten@apache.org>
To: dev@forrest.apache.org
In-Reply-To: <4329FE17.9080603@apache.org>
References: <4328B8A4.7000700@apache.org>
	 <200509150922.16506.sean@inwords.co.za>  <43295281.3010404@apache.org>
	 <1126819740.17350.40.camel@localhost.localdomain>
	 <4329FE17.9080603@apache.org>
Content-Type: text/plain; charset=utf-8
Date: Sun, 18 Sep 2005 18:15:45 +0200
Message-Id: <1127060145.9375.0.camel@localhost>
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Cheers Ross,

that is really nice. :)

salu2

El vie, 16-09-2005 a las 00:04 +0100, Ross Gardler escribi=C3=B3:
> Thorsten Scherler wrote:
> > On Thu, 2005-09-15 at 11:52 +0100, Ross Gardler wrote:
> > ....
> >=20
> >>As things are today it is not possible to have dependencies between=20
> >>plugins. However, Daniel (from Cocoon) showed me how we can use a=20
> >>feature of Cocoon blocks (wiring.xml) to manage ingheritance between=20
> >>plugins.
> >>
> >>In other words we can write a docbook plugin that extends the XHTML=20
> >>plugin. It will use the docbook stylsheets to convert to XHTML and then=
=20
> >>the XHTML plugin to convert to our internal format. I've not found a us=
e=20
> >>case strong enough for me to take the time to implement this yet,=20
> >>however, if anyone wants to tackle it I'll be happy to pass on what=20
> >>Daniel showed me.
> >=20
> >=20
> > Please show us, I would be very interested.
>=20
> The "technical side" is really easy. What I haven't thought through yet=20
> is how to define the dependencies within the plugins.xml file. That is,=20
> if the docbook plugin depends on the XHTML plugin, how do we ensure that=20
> the plugin install system downloads and installs both of them when we=20
> only define the Docbook plugin.
>=20
> Of course, the first instance could rely on the user adding the=20
> dependencies.
>=20
> For the techincal stuf take a look at wiring.xml [1]
>=20
> This file describes the relationship (wiring) between three blocks=20
> test1id, test2id and test3id.
>=20
> test1id is connected to test2id
> test3id is connected to test1id
>=20
> Now look in the sitemaps for these blocks. In the sitemap for test1 you=20
> will see a match like this:
>=20
>        <map:match pattern=3D"test2">
>          <map:generate src=3D"block:test2:/test"/>
>          <map:serialize/>
>        </map:match>
>=20
> The "block:test2" protocol makes a request on test2 (note this is the=20
> name of the connection identified in wiring.xml)
>=20
> You can see other examples of the use of connections in the various=20
> sitemaps. The best way to explore is actually to run the tests and look=20
> at what happens with the various requests.
>=20
> Daniel talked me through this stuf at Apachecon so if you have questions=20
> try asking here first. I don;t guarentee I know the answers but I've not=20
> played with this stuf yet so in exploring the answers I'll learn plenty.
>=20
> Ross
>=20
> [1]=20
> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon=
/test/components/blocks/wiring.xml?view=3Dmarkup