forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: refactoring forrest (views, xhtml2) -- my2c
Date Tue, 20 Sep 2005 08:10:07 GMT
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)


Mime
View raw message