forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [RT] Forrest processing pipeline
Date Thu, 18 Nov 2004 22:24:49 GMT
El lun, 15-11-2004 a las 10:11, Nicola Ken Barozzi escribió:
> I'll try to describe how Forrest should/could do the processing.
> This will be part of our "Forrest 1.0 spec" that will guide us to the 
> first version of our product.
> The items below are conceptual. All references to actual source dirs and 
>   internal or external formats is generic and will be later on specified 
> and changed as needed.
> [Items to be discussed *after* this:
>   * raw files
>   * project directory layout
>   * config file formats
> ]
> Step 1: Resolution (content)
> -------------------


> Forrest has a single conceptual source space, that can initially be 
> thought of as a single directory, the current xdocs dir.
> Every file that is outside of this directory has to be resolved by a 
> locationmap, so that Forrest sees it all as a single directory in any case.
> This source space contains files that a filename and an extension. There 
> should be only one file with a certain name in a certain directory, 
> which will be the main source of our transformation.
> For each URL that is requested, there will be only one source file 
> resolved, which will be our main source.

Can we support something like jsr 170 (Jackrabbit) with this approach?

> Step 2: Format Transformation (content)
> ------------------------------


> In the second step, Forrest transforms the main source to the 
> intermediate format, which is XHTML2 

<map:transform src="*2XHTML2.xsl"/>

> (also automatic transforms from 

<map:transform src="*2XHTML1.xsl"/>

> and HTML will be supported). 

<map:transform src="*2HTML.xsl"/>

> Transformations from HTML and XHTML 
> will be done in the core, while all others will be done by plugins 
> (input plugins).


IMO only <map:transform src="*2XHTML2.xsl"/> belongs in the core. 
We have to create just one contract about the internal format that
forrest is based on.

The rest should be in plugins. What am I saying everything should be
done in plugins. The only thing we will do is distinct between core and
non core plugins. That forces us to implement a free interaction between
plugins. This mechanism, which controls the interaction, has to go to
the core.

Basicly it is the instances of forrest who knows all contracts. I think
the locationmap could be extended with contract information. A contract
is basicly an agreement that certain action will cause certain

> Multiple formats can be asked for the same source: the filename asked 
> will be in the following manner.
>    name.type.format
> IOW:
>    myfile.content.html
>    myfile.javadocs.html
>    myfile.html

Is this like views?

> Step 3: Filtering (content)
> ------------------


> This is a new step, that adds navigation, metadata, extra content and 
> transformations to the content stream.

<map:transform src="NAV2XHTML2"/>
> Navigation is the addition of the 'tab' and 'linkmap' information to the 
> stream.

<map:transform src="META2XHTML2"/>

> Metadata about a page can be added, like the date, page size, etc.
That leads us to the question where to store metadata (example file
my.xml). BTW this is taken from a mail I never send to answer the
"Selective pdf" thread.
1) within each file as inline element.
<metadata type="pi" output-include="rtf,pod,pdf" output-exclude="html"/>

2) outside of the file
  a) in an extra file like my.metadata.xml. For each input file exist 1
metadata file.
<metadata type="pi" output-include="rtf,pod,pdf" output-exclude="html"/>
  b) in an aggregated metadata file. Kind of like site.metadata.xml.
<metadata node="about/index" type="pi" output-include="rtf,pod,pdf"

3) in the site.xml like Sean suggested + modification
a) @attributes
<about label="About">
    <index label="Index" href="index.html" description="Welcome to
      <metadata type="pi" output-include="rtf,pod,pdf"
b) nodes
<about label="About">
    <index label="Index" href="index.html" description="Welcome to
      <metadata type="pi" name="output">

4) in RELAXNG?


> Nuggets of information can be added based on the URL and on the contents 
> of the main source. For example, newsfeeds about the page being processed.

Should go to the metadata like
 <metadata type="nuggets" name="contractName1, contractName2"/>

This way the skin can pull the actual needed content later on (faster).
The information about which nuggets are needed could be stored in ft.

What I missing is:
fbits can be added based on the URL and on the contents of the main
source. For example, specific searchbox for the page being processed.
Should go to the metadata like
 <metadata type="fbit" name="contractName1, contractName2"/>

> Filtering on the main content can be done, like the automatic creation 
> of links based on the site.xml linkmap or footnote processing.
> These filtering steps are to be done by plugins (filtering plugins).

Some of them I reckon will have to go to the core plugins (e.g. nav).

> Step 4: Skinning (presentation)
> ------------------

> Based on the skin specified, the content is transformed in a format that 
> contains presentation information. Example formats are html, fo 
> (formatting objects) and svg.

Here everything will get populated with data that passed to this stage. 

<map:transform src="XHTML2html"/>
<map:transform src="XHTML2fo"/>
<map:transform src="XHTML2svg"/>

> Note that this part adds functionality to the content.

better "adds functionality implementations to the content", because IMO
we should store just metadata in our XHTML2 output and let the skin
decide how to actually implement it.

This way it can be overridden by another implementation of the
functionality very easy.

>  For example, a 
> search item can be displayed, or widgets can be used. These are fbits, 
> or functionality bits, and are different from nuggets, which are extra 
> content.

They are different, indeed, but still they have a lot in common. Some
nuggets will request a special functionality and vice versa. This will
depend on the skin. That is why I think we should store such information
(nuggets & fbits) as metadata first and implemend them now in this

> Note that fbits are skin dependant, so that a skin can decide to 
> implement them or not. 

So are nuggets. That is why we need to insert this decision earlier in
our pipeline. That needs to go into the filtering state.

Trying to say that skins as well filter the content. That are views on a
certain set of data. Remember that I earlier ask about views? ;-)

> The configuration of these bits are to be done 
> with the new generic skinconf format.

That is as well filtering. The ft-approch filters fbits and can filter
    <fbit name="branding-trail-path"/>
    <hook name="intro">
      <fbit name="grouplogo"/>
      <fbit name="projectlogo"/>
      <fbit name="search-input" type="sport"/>
      <nugget name="sportNews"/>

That is why I am thinking ft and skinconf.xml has to be proceded in
filtering stage. -> copyless ;-)

The skining stage has to implemend the actual data, fct, ... by pulling
it in.

> Example of current fbits are the search pane, the project and group 
> logos, the page format selector, etc.
> Step 5: Theming (presentation)
> ------------------
> Here the result of the skinning is given to theming, that adds colors 
> and general appearance info. In html it's css files for example, or the 
> skinconf color information.

Please extend.

Why is this another stage? What is the big differents to skinning? 

We are processing the needed information earlier in our pipeline why
here again?

> Step 6: Serializing (presentation)
> ------------------

<map:serialize type="*"/>
> The presentation is transformed to the actual final format with output 
> plugins. For example a fo presentation can be outputted as pdf, rtf, 
> doc, ps, etc.


BTW did you notice that Nicolas [RT] is a pipeline that could be within
a plugin itself (forrest as meta-plugin)? ;-) 

We should focus on the forrest core (controller) as meta-plugin
contoller. This plugin controlls all other forrest plugins.

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message