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.
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
they use the same stylesheet. Cause lenya comes with a wysiwyg editor
lettin the editor view the same page
the only difference is that you have in this area the possibility to
edit content (you have an extra menubar for editing / publishing)
but the outcome is (almost ) the same so i guess forrest should handle
this part as well
maybe not as you said on the first level of integration
but forrest needs to take care of this part too
{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)
(this is one of the lenya main features) to edit(change the content) the
page as it is
what lenya can not do that easy (as i have seen from Thorsten as he
showed me how NICE forrest works, he simply changed (commented some
lines out in his config file and changed the whole design of the page))
AND THIS IS WHAT WE WANT FORREST TO DO
the styling as it is that quick and simple
and most of all you don't have to deploy once again and restart your
jetty as we had to do in lenya
once lenya is started you cannot influence the style
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
:-David
