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