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 Wed, 24 Aug 2005 13:14:20 GMT
David Podunavac wrote:
> sorry for late responding to your questions! was busy
>>[Note I am confused about this publication-sitemap.xmap file. Does
>>publication in its title mean the publication of documents, or is it
>>the publication that make up a Lenya site? I suspect it is the later
>>very confusing!]


> as we have for each pub(lication) in lenya a separate
> publication-sitemap.xmap this seems to be a publication specific file:
> -IT IS the publication that make up a Lenya site!

OK, thanks for clarifying that.

>>site.xml   |   ????  <-- sitetree.xml
> if i assume that site.xml is a kind of configfile that puts all the
> navigational elements to the site i suggest sitetree.xml would be the
> file you are lookin for. In this sitetree all navigational links are
> stored which will be displayed (if wanted) the way you tell the stylesheet.
> sitetree.xml is for the root navigation, from here there will be
> generated other 'items' like e.g tabs or breadcrumb etc.

Yes, that sounds right.

>>tabs.xml  |   ????  <--
>  this stylesheet only referencese the elements from the sitetree.xml and
> defines how these (here in this case the tabs) should be outputted.
> Like any other xsl in this directory
>  - admin-menu.xsl 
>  -  sitetree2nav.xsl
>  - breadcrumb.xsl 
>  - search.xsl 
>  - tabs.xsl

OK, we are considering merging site.xml and tabs.xml ourselves. 
Generating it from another file is, of course, not a problem. In fact 
this is exactly what the IMSManifest plugin does.

>>*.xml        |   ????  <-- is this a content file ?

Yes, although it is a little more complex than that in some cases. It's 
all to do with our input plugins which allow different source formats to 
be used within Forrest. The most common *.xml file is an XDoc, but it 
may be any other accepted format. However, at this high level we need 
not consider exactly what the content file is, in other words we'll just 
call it a content file.

> if i guess *.xml is any content file in forrest, lenya would use this
> schema
> any content is named index_<LOCALE>.xml
> so if a document is named e.g. "whatever" it should be found under
> whatever/index_<locale>.xmlin the specific area
> while we have different areas authoring stage live
> i hope that helps

OK this is the same as in Forrest (although there may be no <LOCALE> 
part to the filename. In addition in 0.8-dev the location of the file 
need not be in "the specific area", instead it is resolved through our 
locationmap. However, I doubt this will impact on the integration at 
this high level.

> by the way i noticed another thread Thorsten started on the lenya dev
> list maybe we should moved there?

No, not yet, all those who have expressed an interested parties on on 
both lists anyway. At present this is a pretty high level view but it is 
from the perspective of Forrest, whereas the one on the Lenya list is 
from their perspective.

Once we come up with a proposal we can take that to both lists.

>>If lenya can expose the relevant equivalent files via a URL then we
>>simply map the forrest rquired files to the relevant Lenya URL. Then
>>we create a forrest:view that will produce the output that Lenya needs
>>and we are done.
> 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.

{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:

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


to something like


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:


will map to something like


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.


View raw message