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
|