forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: joinin LENYA and FORREST
Date Fri, 26 Aug 2005 10:57:07 GMT
David Podunavac wrote:

>>> this is a part of the doctypes.xmap which is building the requested 
>>> file
>>> via the URL
>>> i don't know if this is what u asked for
>>> <code snippet from doctypes.xmap @
>>> lenya_home/build/lenya/webapp/lenya/pubs/<pubId>
>>> <!-- parametrized doctype matcher -->
>>>       <!-- pattern="{rendertype}/{area}/{doctype}/{document-path}" -->
>>>       <map:match pattern="*/*/*/**.xml">
>>>         <map:generate src="content/{2}/{4}.xml"/>
>>>         <map:transform src="xslt/{3}2xhtml.xsl">
>>>           <map:parameter name="rendertype" value="{1}"/>
>>>           <map:parameter name="nodeid"
>>> value="{page-envelope:document-node-id}"/>
>>>           <map:parameter name="language"
>>> value="{page-envelope:document-language}"/>
>>>         </map:transform>
>>>         <map:serialize type="xml"/>
>>>       </map:match>
>> OK, so this is addressing the content issue. The question is what do 
>> we get when making a request for a document via this pipeline. If I 
>> understand the lenya URLspace correctly {1} will either be 
>> "authoring" or "live". In this first iteration we are not interested 
>> in "authoring", only in the publishing.
> let me just add this
> it is not correct (or as far as i can see) that we are not interested 
> in "authoring" but only in "live"
> let me clear the purpose of this areas.

I did say "In this first iteration we are not interested..." I'll 
explain why...

> the only differece in these areas is, that you as a editor or someone 
> who can edit content will need  the authoring area.
> in the end the output i mean styling of a page looks the same in 
> authoring and live

No they are not the same, in the authoring mode you need many parts of 
Cocoon that are not included with the Forrest version of Cocoon (forms 
and flowscript for example).

In order to use Forres to skin the authoring portion of a lenya 
publication we will need to run Forrest inside an instance of Cocoon. 
I'm currently experimenting with making Forrest work as a Cocoon Block 
(in my 'copious' spare time - don't hold your breath). Once this is done 
we will be able to drop the Forrest block into a Lenya instance, create 
the necessary wiring between the sitemaps and create the authoring 
integration. However, for this first iteration lets keep it simple (this 
is the approach also proposed by Thorsten on the Lenya list).

>> {2} and {4} seem to identify the location of the content file.
>> {3} identifies the source doctype. This looks to me like on of the 
>> later points of integration for Forrest. That is our input plugins 
>> may replace the multiple stylesheets used here. However, we should 
>> not worry about this in the first instance of the integration.
>> So, it looks like this will give us an XHTML document directly from 
>> Lenya, I'm going to proceed as if my interpretation is correct:
> yes it outputs xhtml with almost all xHTML elements like (dont blame 
> me if i am wrong)
> but this is the first of the two transformations
> this first transformation simply puts all the content elements like 
> navigation etc needed for this page in a "simple" xhtml document
> this document will be transformed and styled via the second stylesheet 
> into the final output (the page as you see it in the browser) and this 
> document looks (almost) the same
> in both areas (live and stage)

Now there is a problem for us. We don't want the additional decorations 
(like navigaion). We will have to create a new pipeline, perhaps 
pattern="*/*/*/**.content.xml". This match will give us the pure content 
(as XHTML) and nothing else. As you describe all other content would be 
added by Forrest, this will require us to translate sitemap.xml into 
site.xml, but in this first experiment we should just use a basic hard 
coded site.xml file in Forrest.

>> Lets look at how we build a plugin for this. The place to start 
>> looking is the Daisy plugin. What happens here is we have Daisy 
>> running in one VM and Forrest in another VM. Obviously they are both 
>> on a different port. Later we will (optionally) integrate Forrest and 
>> Daisy/Lenya in the same VM, but lets stay simple for now.
>> In the daisy plugin we map a request to Forrest in the form
>> daisy/**.xml
>> to something like
>> http://DAISY_HOST:DAISY_PORT/.....
>> This request returns a daisy XML document which we then convert to an 
>> XDoc and pass to Forrest.
>> The Lenya plugin will do the same by invoking the match you identify 
>> above. So a request for:
>> Lenya/live/*/*/**.xml
>> will map to something like
>> http://LENYA_HOST:LEYA_PORT/live/{1}/{2}/{3}.xml
>> Since this returns an XHTML document we then use our 
>> html2document.xsl to give us an XDoc and pass this to Forrest.
>> Well, that's the theory anyway, now someone needs to try a simple 
>> experiment. I'll get onto this fairly soon, unless, of course, 
>> someone beats me to it.
>> Ross
> yeah that would be cool but I am not that familiar workin with more VMs
> maybe you can give me a hint/starting help on how that would work
> so i can do the experimenting 

It's just an case of starting Forrest and Lenya on different ports. I 
don't know how you do this with Lenya but for Forrest see


View raw message