forrest-user mailing list archives

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