You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by David Podunavac <dp...@dserv.net> on 2005/08/11 13:31:45 UTC
joinin LENYA and FORREST
Hi devs,
I am David, some of you might remember me from the ApacheCon this year,
anyway I heard the need of joinin LENYA and FORREST and the discussion
monday late night.
As Ross encouraged me to post or to help you out, with the stuff I know
about LENYA. So here it is the things that came to my mind on how stuff
works or the things i know about to let you know, in order to make this
MARRIAGE possible.
I hope this will help:
---------------------------------------------------------------------------------------------------------------------------------
the entry point for lenya is the sitemap.xmap @LENYA_HOME/build/lenya/webapp
-this sitemap defines all the components used, can be compared to the
root sitemap in forrest as far as i can see
-then the authorizer action is being called which mounts the
global-sitemap.xmap
-the global-sitemap handles all the modules i call it modules i dont
know if it is the right name
but what i mean with modules is e.g. the built-in wysiwyg editors, the
search engine, usecases, the i18n stuff the admin-area etc
for all this modules an extra sitemap is mounted
the same with the actual publication as lenya has different
publications (<-- is this the same as your forrest seeds?)
and different areas: areas is the level of published documents e.g if a
document is created it is in the authoring area
when the editor is done writing the doc he submits it and the reviewer
has to publish it
so this document is copied from the authoring area to live and the
visitor can finally view the page
so if your uri looks like this
http://localhost:8888/default/authoring/
http://<SERVER:PORT>/{PUBLICATION}/{AREA}/
so the sitemap.xmap @LENYA_HOME/build/webapp/lenya/pubs/{PUBLICATION}
is called
which mounts the publication-sitemap.xmap in the same directory
this publication-sitemap.xmap mounts the doctypes.xmap and handles the
document aggregation
like navigational elements (breadcrumb, tabs, menus) with the actual
content of the document
after this aggregation it calls the transformation for the doctype
requested
this is when the authorizer checks if the requested url is only for
certain users
i am skippin the long description how lenya might work on this
loading the global-sitemap.xmap @LENYA_HOME/build/webapp
the global-sitemap.xmap is used only internal
here are some tries or ideas on how lenya and forrest could/should work
together
this MARRIAGE(joining lenya and forrest) what i call it now could be
done on the publication-sitemap.xmap level
when we look at the sitemaps of lenya and forrest we will see that they
look alike
take a look at the publication-sitemap.xmap
@lenya-1.2.x/build/lenya/webapp/lenya/pubs/default/
of a clean lenya lines 120ff.
<!-- This is the pipeline that builds the page. It aggregates all
the navigational elements (breadcrumb, tabs, menu) with the actual
content of the document. -->
<map:pipeline>
<!--
/lenyabody-{rendertype}/{publication-id}/{area}/{doctype}/{url} -->
<map:match pattern="lenyabody-*/*/*/*/**">
<map:aggregate element="cmsbody">
<map:part src="cocoon://navigation/{2}/{3}/breadcrumb/{5}.xml"/>
<map:part src="cocoon://navigation/{2}/{3}/tabs/{5}.xml"/>
<map:part src="cocoon://navigation/{2}/{3}/menu/{5}.xml"/>
<map:part src="cocoon://navigation/{2}/{3}/search/{5}.xml"/>
<map:part
src="cocoon:/lenya-document-{1}/{3}/{4}/{page-envelope:document-path}"/>
</map:aggregate>
<map:transform src="xslt/page2xhtml-{4}.xsl">
<map:parameter name="root"
value="{page-envelope:context-prefix}/{2}/{3}"/>
<map:parameter name="url" value="{5}"/>
<map:parameter name="document-id"
value="{page-envelope:document-id}"/>
<map:parameter name="document-type"
value="{page-envelope:document-type}"/>
<map:parameter name="language"
value="{page-envelope:document-language}"/>
</map:transform>
<map:transform type="i18n">
<map:parameter name="locale"
value="{page-envelope:document-language}"/>
</map:transform>
<map:select type="parameter">
<map:parameter name="parameter-selector-test" value="{1}"/>
<map:when test="view">
<map:transform type="link-rewrite"/>
</map:when>
</map:select>
<map:serialize type="xml"/>
</map:match>
</map:pipeline>
and compare this to forrest sitemap.xmap @forrest/main/sitemap
<map:pipeline internal-only="false">
<!--pipeline that "marries" the docs in the root dir with the skin to
produce html-->
<map:match pattern="*.html">
<map:aggregate element="site">
<map:part src="cocoon:/skinconf.xml"/>
<map:part src="cocoon:/build-info"/>
<map:part src="cocoon:/tab-{0}"/>
<map:part src="cocoon:/menu-{0}"/>
<map:part src="cocoon:/body-{0}"/>
</map:aggregate>
<map:call resource="skinit">
<map:parameter name="type" value="site2xhtml"/>
<map:parameter name="path" value="{0}"/>
</map:call>
</map:match>
<!--pipeline that "marries" the docs in all other dirs then root with
the skin to produce html-->
<map:match pattern="**/*.html">
<map:aggregate element="site">
<map:part src="cocoon:/skinconf.xml"/>
<map:part src="cocoon:/build-info"/>
<map:part src="cocoon:/{1}/tab-{2}.html"/>
<map:part src="cocoon:/{1}/menu-{2}.html"/>
<map:part src="cocoon:/{1}/body-{2}.html"/>
</map:aggregate>
<map:call resource="skinit">
<map:parameter name="type" value="site2xhtml"/>
<map:parameter name="path" value="{0}"/>
</map:call>
</map:match>
...
our plan is to integrate forrest into lenya (hope that is okay
with you forrest guys :) )
to do so marcin mentioned that:
lenya should do the matching on the first level than
forrest should receive the content like (menus, tabs, body) from lenya
and transform this content into forrest conform content (so this
content could be used in forrest)
after this step lenya lets forrest do the all the styling
so here is the pseudo pipeline as far as we understood forrest and
lenya
<!-- this is the pipeline that should transform the content
delivered by lenya into forrest -->
<map:match pattern="body-*-*-*.html">
<map:part
src="cocoon:/lenya-document-{1}/{2}/{3}/{page-envelope:document-path}"/>
<map:transform type="TRANSFORM_LENYA2FORREST"/> <!-- need to be
implemented -->
<!-- here is when forrest takes over -->
<map:transform type="idgen"/>
<map:transform type="xinclude"/>
<map:transform type="linkrewriter"
src="cocoon:/{1}linkmap-{2}.html"/> <!-- this parametes is not correct,
but is as i said just an idea on how it could/should work -->
<map:transform
src="resources/stylesheets/declare-broken-site-links.xsl" />
<map:call resource="skinit">
<map:parameter name="type" value="document2html"/>
<map:parameter name="path" value="{1}{2}.html"/>
<map:parameter name="notoc" value="false"/>
</map:call>
</map:match>
<!-- this is the entry point and is a mixture of a forrest and
lenya -->
<map:pipeline>
<!-- this is lenya stuff -->
<!--
/lenyabody-{rendertype}/{publication-id}/{area}/{doctype}/{url} -->
<map:match pattern="lenyabody-*/*/*/*/**">
<!-- and from here on this is forrest stuff -->
<map:aggregate element="site">
<map:part src="cocoon:/skinconf.xml"/>
<map:part src="cocoon:/build-info"/>
<map:part src="cocoon:/body-{1}-{3}-{4}"/>
</map:aggregate>
<map:call resource="skinit">
<map:parameter name="type" value="site2xhtml"/>
<map:parameter name="path" value="{0}"/>
</map:call>
<map:serialize type="xml"/>
</map:match>
</map:pipeline>
sure there are alot of things to do in order to make this run
like adjusting pipelines, parameters etc etc
but we want to help you guys on that but we NEED YOUR HELP and FEEDBACK
please let me know if this thinking makes sense or if there are
things we did not understood or thought about right
if you guys agree with this approach or have any hints or problems
which we haven't thought about let us know
or things you want us to do
feel free
we definitely want to help and wait for some any feedback if this
all makes sense
regards
marcin and david
Hope that helps somehow : )
Re: joinin LENYA and FORREST
Posted by Andreas Hartmann <an...@apache.org>.
David Podunavac wrote:
> Hi devs,
>
> I am David, some of you might remember me from the ApacheCon this year,
> anyway I heard the need of joinin LENYA and FORREST and the discussion
> monday late night.
> As Ross encouraged me to post or to help you out, with the stuff I know
> about LENYA. So here it is the things that came to my mind on how stuff
> works or the things i know about to let you know, in order to make this
> MARRIAGE possible.
> I hope this will help:
<snip what="lenya explainations"/>
Just a small note:
Most of these things refer to the Lenya default publication, not to
the Lenya framework. They are just an example, not mandatory.
-- Andreas
Re: joinin LENYA and FORREST
Posted by Ross Gardler <rg...@apache.org>.
David Podunavac wrote:
>
>>>>
>>>> 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
>>>
>>>
> Okay here is what i did
>
> i changed the port for lenya to 7777
> created a dir <deeTest> in forrest
> stuck to the Using Forrest (v0.7) manual
We can only do this with Forrest 0.8-dev because we need the locationmap
and that is not in 0.7 (Thorsten started a new thread for your errors).
Ross
Re: joinin LENYA and FORREST
Posted by Thorsten Scherler <th...@apache.org>.
Please see "Problems with forrest installation" because we are changing
topics here.
salu2
thorsten
On Sat, 2005-08-27 at 00:52 +0200, David Podunavac wrote:
> >>>
> >>> 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
> >>
> Okay here is what i did
>
> i changed the port for lenya to 7777
> created a dir <deeTest> in forrest
> stuck to the Using Forrest (v0.7) manual
> and did 'forrest seed' on that directory in order to change
> the very last pipeline @src/documentation/sitemap.xmap
> but than this ERROR made me go nuts
>
>
> Exception in thread "main" java.lang.UnsupportedClassVersionError:
> org/apache/forrest/log/ForrestLogTargetFactory (Unsupported major.minor
> version 49.0)
> at java.lang.ClassLoader.defineClass0(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:207)
> at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:171)
> at
> org.apache.avalon.excalibur.logger.DefaultLogTargetFactoryManager.configure(DefaultLogTargetFactoryManager.java:118)
> at
> org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:240)
> at
> org.apache.avalon.excalibur.logger.LogKitLoggerManager.setupTargetFactoryManager(LogKitLoggerManager.java:436)
> at
> org.apache.avalon.excalibur.logger.LogKitLoggerManager.configure(LogKitLoggerManager.java:400)
> at
> org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:240)
> at
> org.apache.cocoon.servlet.CocoonServlet.initLogger(CocoonServlet.java:803)
> at
> org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:295)
> at
> org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:220)
> at
> org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.java:445)
> at
> org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebApplicationHandler.java:150)
> at
> org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:458)
> at org.mortbay.http.HttpServer.start(HttpServer.java:663)
> at org.mortbay.jetty.Server.main(Server.java:429)
>
> BUILD FAILED
> /home/dee/projects/forrest/main/forrest.build.xml:498: Java returned: 1
>
> ------
> <java classname="org.mortbay.jetty.Server"
> dir="${forrest.core.webapp}"
> fork="yes"
> maxmemory="${forrest.maxmemory}"
> failonerror="yes">
> <classpath>
> <path refid="forrest.cp"/>
> </classpath>
> <jvmarg line="${forrest.jvmargs}"/>
> <jvmarg
>
> value="-Djava.endorsed.dirs=${java.endorsed.dirs}${path.separator}${forrest.endorsed.lib-dir}"/>
> <arg value="${forrest.core.webapp}/jettyconf.xml" />
> <syspropertyset>
> <propertyref prefix="forrest."/>
> <propertyref prefix="project."/>
> </syspropertyset>
> </java>
> ---------
>
> ---------------
> sorry 4 buggin u guys with stuff like that
>
> any clue what i do wrong ??
>
> thanks
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: joinin LENYA and FORREST
Posted by David Podunavac <dp...@dserv.net>.
>>>
>>> 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
>>
Okay here is what i did
i changed the port for lenya to 7777
created a dir <deeTest> in forrest
stuck to the Using Forrest (v0.7) manual
and did 'forrest seed' on that directory in order to change
the very last pipeline @src/documentation/sitemap.xmap
but than this ERROR made me go nuts
Exception in thread "main" java.lang.UnsupportedClassVersionError:
org/apache/forrest/log/ForrestLogTargetFactory (Unsupported major.minor
version 49.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:207)
at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:171)
at
org.apache.avalon.excalibur.logger.DefaultLogTargetFactoryManager.configure(DefaultLogTargetFactoryManager.java:118)
at
org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:240)
at
org.apache.avalon.excalibur.logger.LogKitLoggerManager.setupTargetFactoryManager(LogKitLoggerManager.java:436)
at
org.apache.avalon.excalibur.logger.LogKitLoggerManager.configure(LogKitLoggerManager.java:400)
at
org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:240)
at
org.apache.cocoon.servlet.CocoonServlet.initLogger(CocoonServlet.java:803)
at
org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:295)
at
org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:220)
at
org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.java:445)
at
org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebApplicationHandler.java:150)
at
org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:458)
at org.mortbay.http.HttpServer.start(HttpServer.java:663)
at org.mortbay.jetty.Server.main(Server.java:429)
BUILD FAILED
/home/dee/projects/forrest/main/forrest.build.xml:498: Java returned: 1
------
<java classname="org.mortbay.jetty.Server"
dir="${forrest.core.webapp}"
fork="yes"
maxmemory="${forrest.maxmemory}"
failonerror="yes">
<classpath>
<path refid="forrest.cp"/>
</classpath>
<jvmarg line="${forrest.jvmargs}"/>
<jvmarg
value="-Djava.endorsed.dirs=${java.endorsed.dirs}${path.separator}${forrest.endorsed.lib-dir}"/>
<arg value="${forrest.core.webapp}/jettyconf.xml" />
<syspropertyset>
<propertyref prefix="forrest."/>
<propertyref prefix="project."/>
</syspropertyset>
</java>
---------
---------------
sorry 4 buggin u guys with stuff like that
any clue what i do wrong ??
thanks
Re: joinin LENYA and FORREST
Posted by Ross Gardler <rg...@apache.org>.
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
Re: joinin LENYA and FORREST
Posted by David Podunavac <dp...@dserv.net>.
>>
>> 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
Re: joinin LENYA and FORREST
Posted by Ross Gardler <rg...@apache.org>.
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
Re: joinin LENYA and FORREST
Posted by David Podunavac <dp...@dserv.net>.
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!]
>
I agree it is a lil confusing but let me try to explain you how I
understand the publication-sitemap.xmap
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!
> 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.
> 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
> *.xml | ???? <-- is this 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
by the way i noticed another thread Thorsten started on the lenya dev
list maybe we should moved there?
let me know if i can help u somehow or if u want me to do something in
order to work them together
> 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>
>
> Since all data is request directly from Lenya there is no complexities
> with user management and the like as Lenya still has control over all
> this stuff. However, I've not yet thought about how Forrest will pass
> authentication information back and forth. I'd have to explore the
> authentication used in Lenya first.
>
> All the existing publication (as in creating the output) pipelines in
> lenyas sitemaps are removed. All publication is handled by Forrest.
>
> I created a very simple demo of this some time back as a result of a
> discussion with Gregor see
> http://marc.theaimsgroup.com/?l=forrest-dev&m=111814596828488&w=2
>
> Ross
David
Re: joinin LENYA and FORREST
Posted by Ross Gardler <rg...@apache.org>.
David Podunavac wrote:
> I am David, some of you might remember me from the ApacheCon this year,
> anyway I heard the need of joinin LENYA and FORREST and the discussion
> monday late night.
Good to "see" you again.
<snipped what="some background info on Lenya processing"/>
> here are some tries or ideas on how lenya and forrest could/should work
> together
>
> this MARRIAGE(joining lenya and forrest) what i call it now could be
> done on the publication-sitemap.xmap level
There are two aspects to integration of Forrest and Lenya. The first is
the publication aspect, but the Lenya folk also want to leverage the
input side of Forrest. However, since publication is the easier part (at
least to me as a Forrest dev) lets focus on that first.
> when we look at the sitemaps of lenya and forrest we will see that they
> look alike
>
> take a look at the publication-sitemap.xmap
> @lenya-1.2.x/build/lenya/webapp/lenya/pubs/default/
> of a clean lenya lines 120ff.
<snip what="lenya sitemap snippet"/>
[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!]
> and compare this to forrest sitemap.xmap @forrest/main/sitemap
<snip what="forrest sitemap snippet"/>
> our plan is to integrate forrest into lenya (hope that is okay
> with you forrest guys :) )
> to do so marcin mentioned that:
>
> lenya should do the matching on the first level than
> forrest should receive the content like (menus, tabs, body) from lenya
> and transform this content into forrest conform content (so this
> content could be used in forrest)
> after this step lenya lets forrest do the all the styling
For Forrest a request of http://localhost:8888/index.html is processed
as follows:
src -> [input plugin] -> core -> skin -> [output plugin]
Forrest core would make additional requests for different parts of the
page (such as navigation and tabs). So this one reqest would actually
create a number of the above processes to be executed.
You sugest (below) that we create a new sitemap to enable Forrest to
publish content, I'm not sure this is the right approach. Both Lenya and
Forrest are moving targets and keeping these sitemaps synchronised will
require maintenance by someone with a foot in both camps. What we really
need is a way of integrating things in a much more maintainable way.
In the new Locationmap functionality in Forrest 0.8-dev (see
http://forrest.apache.org/docs_0_80/locationmap.html ) we can map a
request for a particular file to a defined location. So for example.
FORREST FILE | LENYA FILE
---------------+-------------
site.xml | ????
tabs.xml | ????
*.xml | ????
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.
Since all data is request directly from Lenya there is no complexities
with user management and the like as Lenya still has control over all
this stuff. However, I've not yet thought about how Forrest will pass
authentication information back and forth. I'd have to explore the
authentication used in Lenya first.
All the existing publication (as in creating the output) pipelines in
lenyas sitemaps are removed. All publication is handled by Forrest.
I created a very simple demo of this some time back as a result of a
discussion with Gregor see
http://marc.theaimsgroup.com/?l=forrest-dev&m=111814596828488&w=2
Ross