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
http://forrest.apache.org/docs_0_80/faq.html#run_port
Ross
