You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ross Gardler <rg...@apache.org> on 2005/09/15 12:52:49 UTC
Chaining plguins (was Re: What does "XHTML2 as an internal document
format" mean?)
Sean Wheller wrote:
> On Thursday 15 September 2005 01:56, Ross Gardler wrote:
>
>>An Example Input Plugin
>>-----------------------
>>
>>It is the job of our input plugins to provide the internal format.
>>Consder a OpenOffice input plugin, it converts the OOo XML format to our
>>internal format. What forrest:contracts does it provide?
>>
>>An OOo document consists of meta-data, content (made up of pages,
>>sections, paragraphs) and style information. So logical contracts would
>>be various meta-data contracts (authors, statistics, abstract,
>>keywords), content (all, page X etc.) and style (produces CSS). This way
>>a user can decide which parts of the original document are used.
>
>
> Most Excellent Ross,
>
> Just a question. How do you propose managing Docbook :-)
>
> Stupid ppl, like me, like to use the power of all the Docbook Stylesheets as
> they do 99% of everything we need for publishing. So, as you know, there is a
> set of XHTML XSLT for DocbookXML2XHTML.
>
> If Forrest could input the XHTML from Docbook it would be so nice.
>
> dbxml > X/HTML (single/chunked) > input > internal > output > formats
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.
Ross
Ross
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
Re: Chaining plguins (was Re: What does "XHTML2 as an internal
document format" mean?)
Posted by Thorsten Scherler <th...@apache.org>.
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 Ross Gardler <rg...@apache.org>.
[Please do not CC me on your replies, I get the messages via the dev
list and it is too easy to reply to the wrong one, which ends up making
this a private discussion]
Sean Wheller wrote:
> On Thursday 15 September 2005 13:23, Ross Gardler wrote:
>
>>There is plenty of discussion about this in the archives, you and I have
>>discussed it to death before - the situation is still the same and the
>>design is still the same, it is unaffected by the move to XHTML2, unless
>>docbook provides a set of stylesheets to XHTML2?
>
>
> Right :-)
>
> Now when would be a good time. Since I think any solution would depend on
> having XHTML2 as core, right? My guess is you need to get XHTML2 outa da way
> before anyone can do anything on the input.
If you want to have a blast at it the XHTML2 plugin in whiteboard is
working with respect to accepting XHTML2 as the content. That plugin
also contains a sample document with all the modules we are using in our
internal subset of XHTML2
A starting point for this work would be the XHTML to XHTML2 input plugin
that would be second in the docbook chain.
No need to wait for us to complete the internal conversion, progress can
be made now.
Ross
Re: Chaining plguins (was Re: What does "XHTML2 as an internal document format" mean?)
Posted by Sean Wheller <se...@inwords.co.za>.
On Thursday 15 September 2005 13:23, Ross Gardler wrote:
> There is plenty of discussion about this in the archives, you and I have
> discussed it to death before - the situation is still the same and the
> design is still the same, it is unaffected by the move to XHTML2, unless
> docbook provides a set of stylesheets to XHTML2?
Right :-)
Now when would be a good time. Since I think any solution would depend on
having XHTML2 as core, right? My guess is you need to get XHTML2 outa da way
before anyone can do anything on the input.
--
Sean Wheller
Technical Author
sean@inwords.co.za
084-854-9408
http://www.inwords.co.za
~~~~~~~~~~~~~~~~~~~~~~~~~
Registered Linux User #375355
http://wenzani.blogspot.com/
Re: Chaining plguins (was Re: What does "XHTML2 as an internal document
format" mean?)
Posted by Ross Gardler <rg...@apache.org>.
Sean Wheller wrote:
> On Thursday 15 September 2005 12:52, 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.
>
>
> Use cases
> 1. http://learnlinux.tsf.org.za
> 2. http://icdl.tsf.org.za
I didn't say there weren't valid use cases I said "I've not found a use
case strong enough for" *me* to put the time into it.
It's your itch, you'll have to scratch it. That is the Open Source way.
There is plenty of discussion about this in the archives, you and I have
discussed it to death before - the situation is still the same and the
design is still the same, it is unaffected by the move to XHTML2, unless
docbook provides a set of stylesheets to XHTML2?
Ross
Re: Chaining plguins (was Re: What does "XHTML2 as an internal document format" mean?)
Posted by Sean Wheller <se...@inwords.co.za>.
On Thursday 15 September 2005 12:52, 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.
Use cases
1. http://learnlinux.tsf.org.za
2. http://icdl.tsf.org.za
--
Sean Wheller
Technical Author
sean@inwords.co.za
084-854-9408
http://www.inwords.co.za
~~~~~~~~~~~~~~~~~~~~~~~~~
Registered Linux User #375355
http://wenzani.blogspot.com/