forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [RT] Forrest processing pipeline
Date Fri, 19 Nov 2004 08:54:28 GMT
Thorsten Scherler wrote:
> 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)
>>-------------------
> 
> <generator/>
> <map:generate/>

Nope, it's before generation. ATM our resolution is based on the 
forrest.properties xdocs and raw dir properties, in the future there 
will be a locationmap.

>>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?

Yes, we can support any input. The locationmap will tell Forrest where 
to take the sources, and that can be from anywhere.

>>Step 2: Format Transformation (content)
>>------------------------------
> 
> <transfomer/>
> <map:transform/>

Not really, for Forrest it's more high level. The fact that in Cocoon we 
also use a transformer is another conceptual level (lower).

>>In the second step, Forrest transforms the main source to the 
>>intermediate format, which is XHTML2 
> 
> <map:transform src="*2XHTML2.xsl"/>

No, not necessarily. I'm talking about input plugins, that also have a 
generation step.

>>(also automatic transforms from 
>>XHTML1 
> 
> <map:transform src="*2XHTML1.xsl"/>

Nope, it's <map:transform src="XHTML12XHTML2.xsl"/>

>>and HTML will be supported). 
> 
> <map:transform src="*2HTML.xsl"/>

Nope, it's <map:transform src="HTMLXHTML2.xsl"/>

>>Transformations from HTML and XHTML 
>>will be done in the core, while all others will be done by plugins 
>>(input plugins).
> 
> Why?
> 
> 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.

Not exactly. I'm saying that only

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

and

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

belong to the core.

This means that plugins can give straight XHTML2, or HTML (which the 
core transforms to XHTML2), or XHTML1 (which the core transforms to XHTML2).

> 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.

I don't want interaction between plugins. It's really difficult to 
maintain and very difficult to do with current Cocoon.

> 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
> consequences. 

Too complicated, it has to be easy! :-)

>>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?

Not exactly, as a view in Cocoon is an *intermediate* processing step. 
Here it's usually a different pipeline.

But conceptually yes, it's a "view" on the content.

>>Step 3: Filtering (content)
>>------------------
> 
> <transfomer/>
> <map:transform/>
> 
>>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"/>

No, not like this. I will have to rewrite this document with an example :-)

>>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). 

ATM our Filtering metadata is in the skinconf file, and things are added 
based on that file.

BTW this is taken from a mail I never send to answer the
> "Selective pdf" thread.
...
> 2) outside of the file
>   a) in an extra file like my.metadata.xml. For each input file exist 1
> metadata file.

Or for each directory.

> <metadatas>
> <metadata type="pi" output-include="rtf,pod,pdf" output-exclude="html"/>
> </metadatas>
...

This could be an idea for changing parts of skinconf for just part of 
the pages. Dunno how to do it though yet.

> ....
> 
> 
>>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"/>

It's getting too complicated! It goes exactly like now. in the skinconf. 
The difference is just the new generic format we had discussed.

>>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)
>>------------------
> 
> <transfomer/>
> <map:transform/>
> 
>>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.

Yes, we are already now including skinconf in the aggregated file, and 
it will remain.

>> 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
> stage.
> 
>>Note that fbits are skin dependant, so that a skin can decide to 
>>implement them or not. 
> 
> So are nuggets. 

No, nuggets are not skin dependant. We could argue that fbits are not 
skin dependant either but *format* dependent, but it will get too 
confusing ;-)

> 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
> nuggets.
> <forrest-template>
>     <fbit name="branding-trail-path"/>
>     <hook name="intro">
>       <fbit name="grouplogo"/>
>       <fbit name="projectlogo"/>
>       <fbit name="search-input" type="sport"/>
>       <nugget name="sportNews"/>
>     </hook>
> </forrest-template>

No, here you are mixing content and view...

Ok, I will create some documents that show what happens at every stage, 
so it will be clearer what I intend.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message