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.
FORREST FILE | LENYA FILE
---------------+-------------
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 | ???? <--
lenya_home/build/lenya/webapp/lenya/xslt/navigation/tabs.xsl
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
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
