You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@forrest.apache.org by Johannes Schaefer <jo...@uidesign.de> on 2005/09/20 08:35:14 UTC
refactoring forrest (views, xhtml2) -- my2c
Ross Gardler wrote on 2005-09-15, 12:52:
> I, and I assume all other devs, would not be able to excuse you if
> you did *not* chime in. Your input and oversight is valuable (the
> same goes for anyone else unable to do code at any particular
> time).
Ross' comment encourages me to write down some of my thoughts ...
Note: he does *not* refer to *my* input and oversight, of course :-)
If you think it's rubbish, simply send a "nonsense, start coding!"
and I'll not be offended but start coding (as soon as possible,
that is, my life still being spread out between work, home, wife
and son, all in different places).
I couldn't even manage to cross-check with views to see the overlap.
So, I'm lurking around the list and reading the the IRC protocols.
And there's this idea ... why do we need an internal format?
[HTML-content]: -------\
\
+--+--+----> :[page]: --+--> :[output]
/ / /
[tab-stucture]: ----/ / /
[toc]: ------------------/ /
[css]: ------/
Let's start with [page].
This would define what we want to have in that page:
* post-condition: an output that is "themable" (in some way)
* pre-conditions: [toc], [tab-structure], [content]
In the diagram above (still trying to get close to Ross' level of
ASCII-art) the content would be provided as HTML, so we can use it
directly. The other two appear from somewhere directly as well
(think of site.xml and tabs.xml). Themeing here is CSS.
Let's get more complicated
[xdoc-content]: --> :[HTML-content]: --\
\
+--+---> :[page]:
/ /
[tab-stucture]: ------/ /
[toc]: -----------------/
And even more complicated
[xhtml2-content]: --> :[chapter-1]: ---+------+--> :[page]:
/ /
... --> :[table]: ----------------/ /
/
[docbook-content]: --> :[section-4]: -----/
Which means that we insert a table from somewhere between chapter 1
of some XHTML2 content and section 4 of some DocBook content (hey,
wasn't there some table-plugin?).
About the notation (ad-hoc invention to write these thoughts down):
:[ input connector, specifies which input is expected
name some kind of "unit" with two "connectors" at the ends
]: output connector, specifies which output is provided
One always can connect two :: if post- matches pre-condition.
Where's Forrest gone? Core, Plugins, Views?
[Input-plugin]::[ C O R E ]::[Output-plugin]
At the connection ]::[ lives xdoc and eventually XHTML2.
So, right now (forrest v0.7) we have a lot of [units]: with an
output-connector being xdoc and a lot of :[units] with an input-
connector being xdoc. They are rather coarse, i.e. processing
a complete "page"/"document"/"request" at once. And there's just
one intermediate step [core].
Forrest would provide a lot of default [units] like the standard
page with menu and tabs and footer and so on. Standard input is
XHTML2, output XHTML2, HTML, FO, VoiceML.
And it provides the wiring.
But such a "unit" could do much more: extract chapters/sections
metadata, style or whatsoever from a previous connector.
As long there's a "unit" that provides the requested connector
Forrest could go and fetch the next piece of information to join
with the final output.
I have a use-case like this
[myDTD-content]::[docbook-content]::[xdoc-content]: ...
and we use a project-sitemap to process the first two using the
sdocbook plugin's stylesheets. This is where the wiring thing
would come in handy.
Where to start processing then? At what I sketched above as
[page] or [output]. Going backward until Forrest finds some
unit with no pre-condition. But intermediate steps may be useful,
too. Imagine a XHTML2-enabled browser. An intranet that uses a XML
representation to apply the CI style. Or input into a professional
publishing chain, thus using Forrest as pre-print system.
If I want to have PDF output I could either start after [page]
by providing FO output from here or I could create a new [page]
requesting the same input but providing FO output or I could mix
the two using [page] as main content, converting it to FO plus
add some extra stuff like [title-page], [index A..Z].
Final [output] would then be done by FOP (after themeing?!).
But then, all this looks much like Cocoon's pipelines:
:[ = generator
pipeline
]: = serializer
Even more if I go for a more xml-ish notation:
<!-- are these "nuggets"?
or map:aggregate from cocoon? -->
<page name="simple-page">
<toc src="site-def:toc"/>
<tabs src="tabs-def:tabs"/>
<content src="file:abc.html"/> <!-- by-passing internal format -->
</page>
<!-- is this themeing? -->
<output name="final-page" format="html">
<page src="simple-page"/>
<theme src="file:simple.css"/>
</output>
<!-- is this a cocoon pipeline? -->
<connector name="site-def" pre="true">
<provides name="toc">
<generate src="site.xml"/>
<transform src="site2toc.xsl"/>
<serialize type="html">
</provides>
</connector>
Now, I'm rather more confused than before and I tend to
respond to myself: "nonsense, start coding!"
Cheers
Johannes
--
User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg
Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99
Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 *
D-81825 München
www.uidesign.de
Buch "User Interface Tuning" von Joachim Machate & Michael Burmester
www.user-interface-tuning.de
Re: refactoring forrest (views, xhtml2) -- my2c
Posted by Thorsten Scherler <th...@apache.org>.
Do you mean someting like:
http://svn.apache.org/viewcvs?rev=290290&view=rev
salu2
El mar, 20-09-2005 a las 09:06 +0200, Johannes Schaefer escribió:
> sorry, this was definitely meant for the dev-list.
> Johannes
>
> Johannes Schaefer schrieb:
> > Ross Gardler wrote on 2005-09-15, 12:52:
> >
> >>I, and I assume all other devs, would not be able to excuse you if
> >>you did *not* chime in. Your input and oversight is valuable (the
> >>same goes for anyone else unable to do code at any particular
> >>time).
> >
> >
> > Ross' comment encourages me to write down some of my thoughts ...
> > Note: he does *not* refer to *my* input and oversight, of course :-)
> >
> > If you think it's rubbish, simply send a "nonsense, start coding!"
> > and I'll not be offended but start coding (as soon as possible,
> > that is, my life still being spread out between work, home, wife
> > and son, all in different places).
> >
> > I couldn't even manage to cross-check with views to see the overlap.
> >
> > So, I'm lurking around the list and reading the the IRC protocols.
> > And there's this idea ... why do we need an internal format?
> >
> > [HTML-content]: -------\
> > \
> > +--+--+----> :[page]: --+--> :[output]
> > / / /
> > [tab-stucture]: ----/ / /
> > [toc]: ------------------/ /
> > [css]: ------/
> >
> > Let's start with [page].
> > This would define what we want to have in that page:
> > * post-condition: an output that is "themable" (in some way)
> > * pre-conditions: [toc], [tab-structure], [content]
> >
> > In the diagram above (still trying to get close to Ross' level of
> > ASCII-art) the content would be provided as HTML, so we can use it
> > directly. The other two appear from somewhere directly as well
> > (think of site.xml and tabs.xml). Themeing here is CSS.
> >
> > Let's get more complicated
> >
> > [xdoc-content]: --> :[HTML-content]: --\
> > \
> > +--+---> :[page]:
> > / /
> > [tab-stucture]: ------/ /
> > [toc]: -----------------/
> >
> > And even more complicated
> >
> > [xhtml2-content]: --> :[chapter-1]: ---+------+--> :[page]:
> > / /
> > ... --> :[table]: ----------------/ /
> > /
> > [docbook-content]: --> :[section-4]: -----/
> >
> > Which means that we insert a table from somewhere between chapter 1
> > of some XHTML2 content and section 4 of some DocBook content (hey,
> > wasn't there some table-plugin?).
> >
> > About the notation (ad-hoc invention to write these thoughts down):
> > :[ input connector, specifies which input is expected
> > name some kind of "unit" with two "connectors" at the ends
> > ]: output connector, specifies which output is provided
> >
> > One always can connect two :: if post- matches pre-condition.
> >
> > Where's Forrest gone? Core, Plugins, Views?
> >
> > [Input-plugin]::[ C O R E ]::[Output-plugin]
> >
> > At the connection ]::[ lives xdoc and eventually XHTML2.
> >
> > So, right now (forrest v0.7) we have a lot of [units]: with an
> > output-connector being xdoc and a lot of :[units] with an input-
> > connector being xdoc. They are rather coarse, i.e. processing
> > a complete "page"/"document"/"request" at once. And there's just
> > one intermediate step [core].
> >
> > Forrest would provide a lot of default [units] like the standard
> > page with menu and tabs and footer and so on. Standard input is
> > XHTML2, output XHTML2, HTML, FO, VoiceML.
> > And it provides the wiring.
> >
> > But such a "unit" could do much more: extract chapters/sections
> > metadata, style or whatsoever from a previous connector.
> > As long there's a "unit" that provides the requested connector
> > Forrest could go and fetch the next piece of information to join
> > with the final output.
> >
> > I have a use-case like this
> > [myDTD-content]::[docbook-content]::[xdoc-content]: ...
> > and we use a project-sitemap to process the first two using the
> > sdocbook plugin's stylesheets. This is where the wiring thing
> > would come in handy.
> >
> > Where to start processing then? At what I sketched above as
> > [page] or [output]. Going backward until Forrest finds some
> > unit with no pre-condition. But intermediate steps may be useful,
> > too. Imagine a XHTML2-enabled browser. An intranet that uses a XML
> > representation to apply the CI style. Or input into a professional
> > publishing chain, thus using Forrest as pre-print system.
> >
> > If I want to have PDF output I could either start after [page]
> > by providing FO output from here or I could create a new [page]
> > requesting the same input but providing FO output or I could mix
> > the two using [page] as main content, converting it to FO plus
> > add some extra stuff like [title-page], [index A..Z].
> > Final [output] would then be done by FOP (after themeing?!).
> >
> >
> > But then, all this looks much like Cocoon's pipelines:
> > :[ = generator
> > pipeline
> > ]: = serializer
> >
> > Even more if I go for a more xml-ish notation:
> >
> > <!-- are these "nuggets"?
> > or map:aggregate from cocoon? -->
> > <page name="simple-page">
> > <toc src="site-def:toc"/>
> > <tabs src="tabs-def:tabs"/>
> > <content src="file:abc.html"/> <!-- by-passing internal format -->
> > </page>
> >
> > <!-- is this themeing? -->
> > <output name="final-page" format="html">
> > <page src="simple-page"/>
> > <theme src="file:simple.css"/>
> > </output>
> >
> > <!-- is this a cocoon pipeline? -->
> > <connector name="site-def" pre="true">
> > <provides name="toc">
> > <generate src="site.xml"/>
> > <transform src="site2toc.xsl"/>
> > <serialize type="html">
> > </provides>
> > </connector>
> >
> > Now, I'm rather more confused than before and I tend to
> > respond to myself: "nonsense, start coding!"
> >
> > Cheers
> > Johannes
> >
> >
>
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: refactoring forrest (views, xhtml2) -- my2c
Posted by Johannes Schaefer <jo...@uidesign.de>.
sorry, this was definitely meant for the dev-list.
Johannes
Johannes Schaefer schrieb:
> Ross Gardler wrote on 2005-09-15, 12:52:
>
>>I, and I assume all other devs, would not be able to excuse you if
>>you did *not* chime in. Your input and oversight is valuable (the
>>same goes for anyone else unable to do code at any particular
>>time).
>
>
> Ross' comment encourages me to write down some of my thoughts ...
> Note: he does *not* refer to *my* input and oversight, of course :-)
>
> If you think it's rubbish, simply send a "nonsense, start coding!"
> and I'll not be offended but start coding (as soon as possible,
> that is, my life still being spread out between work, home, wife
> and son, all in different places).
>
> I couldn't even manage to cross-check with views to see the overlap.
>
> So, I'm lurking around the list and reading the the IRC protocols.
> And there's this idea ... why do we need an internal format?
>
> [HTML-content]: -------\
> \
> +--+--+----> :[page]: --+--> :[output]
> / / /
> [tab-stucture]: ----/ / /
> [toc]: ------------------/ /
> [css]: ------/
>
> Let's start with [page].
> This would define what we want to have in that page:
> * post-condition: an output that is "themable" (in some way)
> * pre-conditions: [toc], [tab-structure], [content]
>
> In the diagram above (still trying to get close to Ross' level of
> ASCII-art) the content would be provided as HTML, so we can use it
> directly. The other two appear from somewhere directly as well
> (think of site.xml and tabs.xml). Themeing here is CSS.
>
> Let's get more complicated
>
> [xdoc-content]: --> :[HTML-content]: --\
> \
> +--+---> :[page]:
> / /
> [tab-stucture]: ------/ /
> [toc]: -----------------/
>
> And even more complicated
>
> [xhtml2-content]: --> :[chapter-1]: ---+------+--> :[page]:
> / /
> ... --> :[table]: ----------------/ /
> /
> [docbook-content]: --> :[section-4]: -----/
>
> Which means that we insert a table from somewhere between chapter 1
> of some XHTML2 content and section 4 of some DocBook content (hey,
> wasn't there some table-plugin?).
>
> About the notation (ad-hoc invention to write these thoughts down):
> :[ input connector, specifies which input is expected
> name some kind of "unit" with two "connectors" at the ends
> ]: output connector, specifies which output is provided
>
> One always can connect two :: if post- matches pre-condition.
>
> Where's Forrest gone? Core, Plugins, Views?
>
> [Input-plugin]::[ C O R E ]::[Output-plugin]
>
> At the connection ]::[ lives xdoc and eventually XHTML2.
>
> So, right now (forrest v0.7) we have a lot of [units]: with an
> output-connector being xdoc and a lot of :[units] with an input-
> connector being xdoc. They are rather coarse, i.e. processing
> a complete "page"/"document"/"request" at once. And there's just
> one intermediate step [core].
>
> Forrest would provide a lot of default [units] like the standard
> page with menu and tabs and footer and so on. Standard input is
> XHTML2, output XHTML2, HTML, FO, VoiceML.
> And it provides the wiring.
>
> But such a "unit" could do much more: extract chapters/sections
> metadata, style or whatsoever from a previous connector.
> As long there's a "unit" that provides the requested connector
> Forrest could go and fetch the next piece of information to join
> with the final output.
>
> I have a use-case like this
> [myDTD-content]::[docbook-content]::[xdoc-content]: ...
> and we use a project-sitemap to process the first two using the
> sdocbook plugin's stylesheets. This is where the wiring thing
> would come in handy.
>
> Where to start processing then? At what I sketched above as
> [page] or [output]. Going backward until Forrest finds some
> unit with no pre-condition. But intermediate steps may be useful,
> too. Imagine a XHTML2-enabled browser. An intranet that uses a XML
> representation to apply the CI style. Or input into a professional
> publishing chain, thus using Forrest as pre-print system.
>
> If I want to have PDF output I could either start after [page]
> by providing FO output from here or I could create a new [page]
> requesting the same input but providing FO output or I could mix
> the two using [page] as main content, converting it to FO plus
> add some extra stuff like [title-page], [index A..Z].
> Final [output] would then be done by FOP (after themeing?!).
>
>
> But then, all this looks much like Cocoon's pipelines:
> :[ = generator
> pipeline
> ]: = serializer
>
> Even more if I go for a more xml-ish notation:
>
> <!-- are these "nuggets"?
> or map:aggregate from cocoon? -->
> <page name="simple-page">
> <toc src="site-def:toc"/>
> <tabs src="tabs-def:tabs"/>
> <content src="file:abc.html"/> <!-- by-passing internal format -->
> </page>
>
> <!-- is this themeing? -->
> <output name="final-page" format="html">
> <page src="simple-page"/>
> <theme src="file:simple.css"/>
> </output>
>
> <!-- is this a cocoon pipeline? -->
> <connector name="site-def" pre="true">
> <provides name="toc">
> <generate src="site.xml"/>
> <transform src="site2toc.xsl"/>
> <serialize type="html">
> </provides>
> </connector>
>
> Now, I'm rather more confused than before and I tend to
> respond to myself: "nonsense, start coding!"
>
> Cheers
> Johannes
>
>
--
User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg
Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99
Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 *
D-81825 München
www.uidesign.de
Buch "User Interface Tuning" von Joachim Machate & Michael Burmester
www.user-interface-tuning.de
Re: refactoring forrest (views, xhtml2) -- my2c
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Johannes Schaefer wrote:
>
>> Ross Gardler wrote on 2005-09-15, 12:52:
>
>>> I, and I assume all other devs, would not be able to excuse you if
>>> you did *not* chime in. Your input and oversight is valuable (the
>>> same goes for anyone else unable to do code at any particular
>>> time).
>>
>>
>>
>> Ross' comment encourages me to write down some of my thoughts ...
>> Note: he does *not* refer to *my* input and oversight, of course :-)
:-) I was, of course, referring to all people on this list.
>> So, I'm lurking around the list and reading the the IRC protocols.
>> And there's this idea ... why do we need an internal format?
Aggg... the why do we need an internal format question.... again...
I think the explanation in [1] is the clearest (read point 2 onwards)
However, the rest of your post is a *great* description of what I was
tryin gto get across in my mail to this list prior to the IRC session
[2] and in the IRC session itself [3]. The only difference is that I
still have the internal format (for the reasons described in [1]).
It turned out (during the IRC session) that Thorsten was thinking the
same thing and has already implemented this in views :-))
Ross
[1] http://marc.theaimsgroup.com/?l=forrest-dev&m=109870885916860&w=2
[2] http://marc.theaimsgroup.com/?l=forrest-dev&m=112674219803048&w=2
[3]
http://svn.apache.org/viewcvs.cgi/forrest/events/forrest-tuesdays/20050918-log.txt?rev=290041&view=markup
Re: refactoring forrest (views, xhtml2) -- my2c
Posted by Ross Gardler <rg...@apache.org>.
Johannes Schaefer wrote:
> Ross Gardler wrote on 2005-09-15, 12:52:
Replying to dev list to get it in the right place. No comments from me
yet, I want to leave the original unedited for the archive.
>>I, and I assume all other devs, would not be able to excuse you if
>>you did *not* chime in. Your input and oversight is valuable (the
>>same goes for anyone else unable to do code at any particular
>>time).
>
>
> Ross' comment encourages me to write down some of my thoughts ...
> Note: he does *not* refer to *my* input and oversight, of course :-)
>
> If you think it's rubbish, simply send a "nonsense, start coding!"
> and I'll not be offended but start coding (as soon as possible,
> that is, my life still being spread out between work, home, wife
> and son, all in different places).
>
> I couldn't even manage to cross-check with views to see the overlap.
>
> So, I'm lurking around the list and reading the the IRC protocols.
> And there's this idea ... why do we need an internal format?
>
> [HTML-content]: -------\
> \
> +--+--+----> :[page]: --+--> :[output]
> / / /
> [tab-stucture]: ----/ / /
> [toc]: ------------------/ /
> [css]: ------/
>
> Let's start with [page].
> This would define what we want to have in that page:
> * post-condition: an output that is "themable" (in some way)
> * pre-conditions: [toc], [tab-structure], [content]
>
> In the diagram above (still trying to get close to Ross' level of
> ASCII-art) the content would be provided as HTML, so we can use it
> directly. The other two appear from somewhere directly as well
> (think of site.xml and tabs.xml). Themeing here is CSS.
>
> Let's get more complicated
>
> [xdoc-content]: --> :[HTML-content]: --\
> \
> +--+---> :[page]:
> / /
> [tab-stucture]: ------/ /
> [toc]: -----------------/
>
> And even more complicated
>
> [xhtml2-content]: --> :[chapter-1]: ---+------+--> :[page]:
> / /
> ... --> :[table]: ----------------/ /
> /
> [docbook-content]: --> :[section-4]: -----/
>
> Which means that we insert a table from somewhere between chapter 1
> of some XHTML2 content and section 4 of some DocBook content (hey,
> wasn't there some table-plugin?).
>
> About the notation (ad-hoc invention to write these thoughts down):
> :[ input connector, specifies which input is expected
> name some kind of "unit" with two "connectors" at the ends
> ]: output connector, specifies which output is provided
>
> One always can connect two :: if post- matches pre-condition.
>
> Where's Forrest gone? Core, Plugins, Views?
>
> [Input-plugin]::[ C O R E ]::[Output-plugin]
>
> At the connection ]::[ lives xdoc and eventually XHTML2.
>
> So, right now (forrest v0.7) we have a lot of [units]: with an
> output-connector being xdoc and a lot of :[units] with an input-
> connector being xdoc. They are rather coarse, i.e. processing
> a complete "page"/"document"/"request" at once. And there's just
> one intermediate step [core].
>
> Forrest would provide a lot of default [units] like the standard
> page with menu and tabs and footer and so on. Standard input is
> XHTML2, output XHTML2, HTML, FO, VoiceML.
> And it provides the wiring.
>
> But such a "unit" could do much more: extract chapters/sections
> metadata, style or whatsoever from a previous connector.
> As long there's a "unit" that provides the requested connector
> Forrest could go and fetch the next piece of information to join
> with the final output.
>
> I have a use-case like this
> [myDTD-content]::[docbook-content]::[xdoc-content]: ...
> and we use a project-sitemap to process the first two using the
> sdocbook plugin's stylesheets. This is where the wiring thing
> would come in handy.
>
> Where to start processing then? At what I sketched above as
> [page] or [output]. Going backward until Forrest finds some
> unit with no pre-condition. But intermediate steps may be useful,
> too. Imagine a XHTML2-enabled browser. An intranet that uses a XML
> representation to apply the CI style. Or input into a professional
> publishing chain, thus using Forrest as pre-print system.
>
> If I want to have PDF output I could either start after [page]
> by providing FO output from here or I could create a new [page]
> requesting the same input but providing FO output or I could mix
> the two using [page] as main content, converting it to FO plus
> add some extra stuff like [title-page], [index A..Z].
> Final [output] would then be done by FOP (after themeing?!).
>
>
> But then, all this looks much like Cocoon's pipelines:
> :[ = generator
> pipeline
> ]: = serializer
>
> Even more if I go for a more xml-ish notation:
>
> <!-- are these "nuggets"?
> or map:aggregate from cocoon? -->
> <page name="simple-page">
> <toc src="site-def:toc"/>
> <tabs src="tabs-def:tabs"/>
> <content src="file:abc.html"/> <!-- by-passing internal format -->
> </page>
>
> <!-- is this themeing? -->
> <output name="final-page" format="html">
> <page src="simple-page"/>
> <theme src="file:simple.css"/>
> </output>
>
> <!-- is this a cocoon pipeline? -->
> <connector name="site-def" pre="true">
> <provides name="toc">
> <generate src="site.xml"/>
> <transform src="site2toc.xsl"/>
> <serialize type="html">
> </provides>
> </connector>
>
> Now, I'm rather more confused than before and I tend to
> respond to myself: "nonsense, start coding!"
>
> Cheers
> Johannes
>
>
Re: refactoring forrest (views, xhtml2) -- my2c
Posted by Johannes Schaefer <jo...@uidesign.de>.
sorry, this was definitely meant for the dev-list.
Johannes
Johannes Schaefer schrieb:
> Ross Gardler wrote on 2005-09-15, 12:52:
>
>>I, and I assume all other devs, would not be able to excuse you if
>>you did *not* chime in. Your input and oversight is valuable (the
>>same goes for anyone else unable to do code at any particular
>>time).
>
>
> Ross' comment encourages me to write down some of my thoughts ...
> Note: he does *not* refer to *my* input and oversight, of course :-)
>
> If you think it's rubbish, simply send a "nonsense, start coding!"
> and I'll not be offended but start coding (as soon as possible,
> that is, my life still being spread out between work, home, wife
> and son, all in different places).
>
> I couldn't even manage to cross-check with views to see the overlap.
>
> So, I'm lurking around the list and reading the the IRC protocols.
> And there's this idea ... why do we need an internal format?
>
> [HTML-content]: -------\
> \
> +--+--+----> :[page]: --+--> :[output]
> / / /
> [tab-stucture]: ----/ / /
> [toc]: ------------------/ /
> [css]: ------/
>
> Let's start with [page].
> This would define what we want to have in that page:
> * post-condition: an output that is "themable" (in some way)
> * pre-conditions: [toc], [tab-structure], [content]
>
> In the diagram above (still trying to get close to Ross' level of
> ASCII-art) the content would be provided as HTML, so we can use it
> directly. The other two appear from somewhere directly as well
> (think of site.xml and tabs.xml). Themeing here is CSS.
>
> Let's get more complicated
>
> [xdoc-content]: --> :[HTML-content]: --\
> \
> +--+---> :[page]:
> / /
> [tab-stucture]: ------/ /
> [toc]: -----------------/
>
> And even more complicated
>
> [xhtml2-content]: --> :[chapter-1]: ---+------+--> :[page]:
> / /
> ... --> :[table]: ----------------/ /
> /
> [docbook-content]: --> :[section-4]: -----/
>
> Which means that we insert a table from somewhere between chapter 1
> of some XHTML2 content and section 4 of some DocBook content (hey,
> wasn't there some table-plugin?).
>
> About the notation (ad-hoc invention to write these thoughts down):
> :[ input connector, specifies which input is expected
> name some kind of "unit" with two "connectors" at the ends
> ]: output connector, specifies which output is provided
>
> One always can connect two :: if post- matches pre-condition.
>
> Where's Forrest gone? Core, Plugins, Views?
>
> [Input-plugin]::[ C O R E ]::[Output-plugin]
>
> At the connection ]::[ lives xdoc and eventually XHTML2.
>
> So, right now (forrest v0.7) we have a lot of [units]: with an
> output-connector being xdoc and a lot of :[units] with an input-
> connector being xdoc. They are rather coarse, i.e. processing
> a complete "page"/"document"/"request" at once. And there's just
> one intermediate step [core].
>
> Forrest would provide a lot of default [units] like the standard
> page with menu and tabs and footer and so on. Standard input is
> XHTML2, output XHTML2, HTML, FO, VoiceML.
> And it provides the wiring.
>
> But such a "unit" could do much more: extract chapters/sections
> metadata, style or whatsoever from a previous connector.
> As long there's a "unit" that provides the requested connector
> Forrest could go and fetch the next piece of information to join
> with the final output.
>
> I have a use-case like this
> [myDTD-content]::[docbook-content]::[xdoc-content]: ...
> and we use a project-sitemap to process the first two using the
> sdocbook plugin's stylesheets. This is where the wiring thing
> would come in handy.
>
> Where to start processing then? At what I sketched above as
> [page] or [output]. Going backward until Forrest finds some
> unit with no pre-condition. But intermediate steps may be useful,
> too. Imagine a XHTML2-enabled browser. An intranet that uses a XML
> representation to apply the CI style. Or input into a professional
> publishing chain, thus using Forrest as pre-print system.
>
> If I want to have PDF output I could either start after [page]
> by providing FO output from here or I could create a new [page]
> requesting the same input but providing FO output or I could mix
> the two using [page] as main content, converting it to FO plus
> add some extra stuff like [title-page], [index A..Z].
> Final [output] would then be done by FOP (after themeing?!).
>
>
> But then, all this looks much like Cocoon's pipelines:
> :[ = generator
> pipeline
> ]: = serializer
>
> Even more if I go for a more xml-ish notation:
>
> <!-- are these "nuggets"?
> or map:aggregate from cocoon? -->
> <page name="simple-page">
> <toc src="site-def:toc"/>
> <tabs src="tabs-def:tabs"/>
> <content src="file:abc.html"/> <!-- by-passing internal format -->
> </page>
>
> <!-- is this themeing? -->
> <output name="final-page" format="html">
> <page src="simple-page"/>
> <theme src="file:simple.css"/>
> </output>
>
> <!-- is this a cocoon pipeline? -->
> <connector name="site-def" pre="true">
> <provides name="toc">
> <generate src="site.xml"/>
> <transform src="site2toc.xsl"/>
> <serialize type="html">
> </provides>
> </connector>
>
> Now, I'm rather more confused than before and I tend to
> respond to myself: "nonsense, start coding!"
>
> Cheers
> Johannes
>
>
--
User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg
Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99
Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 *
D-81825 München
www.uidesign.de
Buch "User Interface Tuning" von Joachim Machate & Michael Burmester
www.user-interface-tuning.de