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
