forrest-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Schaefer <johannes.schae...@uidesign.de>
Subject Re: refactoring forrest (views, xhtml2) -- my2c
Date Tue, 20 Sep 2005 07:06:26 GMT
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

Mime
View raw message