You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Thorsten Scherler <th...@apache.org> on 2005/04/20 10:32:16 UTC
Lenya and forrest integration
Sorry for the crosspost but it seems to be from interest for both
lists. ;-)
Hello devs,
my customer wants to have forrest in lenya (or vice versa). :)
The question that pops into to my head is the compatibility between the
cocoon versions used by lenya/forrest.
Lenya is officially supporting 2.1.6 (but 2.1.7 is working fine).
Forrest is using 2.2-dev.
Will I run into problems because of that?
What do both lists think how to overcome this problem?
I reckon I have to change the dir structure from either lenya or forrest
to make the forrest project files editable within lenya. Which app would
be best to "learn" the other site structure.
What do both projects think which one should become the main app (lenya
or forrest)?
Another more lenya specific question is the usage of 1.4. for the
integration. We decided to release 1.4 within 2-3 month, do we consider
this release as (relatively) stable?
TIA
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Lenya and forrest integration
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-04-21 at 10:51 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Wed, 2005-04-20 at 14:41 -0400, Gregor J. Rothfuss wrote:
> >
> >>Thorsten Scherler wrote:
> ...
>
> >>from what i understand, forrest has a superior concept of 'resource
> >>types' (plugins in forrest lingo), pluggable sitemap components to
> >>handle rendering of new sorts of content.
> >>
> >
> >
> > In forrest we support three kind of plugins:
> > -input
> > -internal
> > -output
> >
> >
> >>lenya has a superior concept for bundling functionality (java, etc) with
> >>the usecase framework.
> >
> >
> > Actually I would like to have both concepts (bundling functionality and resource types)
> > together. Lets each project concentrate on what is best on and have an interface connect
> > them both. It should be working in forrest and lenya via plugins (lenya2forrest)
> > and usecases (forrest2lenya).
>
> Forrest Plugins can bundle extra functionality into Forrest (Java etc.)
> Basically, anything that can be done in Cocoon can be done in Forrest
> since Forrest is a Cocoon application (of course this is also true of
> Lenya).
>
> I have (almost) automated the conversion of Cocoon Blocks into Forrest
> plugins. I'm just stuck on how to embed extensions to the web.xml file.
> This is a problem that Cocoon will have to address as they work towards
> "real blocks", so I'm waiting for them rather than doing it alone.
>
All this work we (as in lenya) do not have to do again but we *could*
use it *if* we (as in lenya) decide to find a way to allow forrest
plugins to be mounted in lenya.
Like I said above forrest works with
-input
-internal
-output
plugins.
The plugin concept is quite easy to understand as shown as follow, it is
a simple mount in the main sitemap.xmap of forrest (found in
{forrest-trunk}/main/webapp/sitemap.xmap).
<!--This allows project specific sitemap's that can override some or
all matches of this sitemap -->
<map:pipeline internal-only="false">
<map:select type="exists">
<map:when test="{project:sitemap}">
<map:mount uri-prefix="" src="{project:sitemap}"
check-reload="yes"
pass-through="true"/>
</map:when>
</map:select>
</map:pipeline>
<!--This allows to override all internal specific matches by a plugin-->
<map:pipeline internal-only="false">
<map:select type="exists">
<map:when test="{project:temp-dir}/internal.xmap">
<map:mount uri-prefix="" src="{project:temp-dir}/internal.xmap"
check-reload="yes" pass-through="true"/>
</map:when>
</map:select>
</map:pipeline>
Like I said in my other mail *one* big advantage of forrest over lenya
is that it is working *copyless* this makes it possible to create a
project (forrest seed) anywhere on the file system and run "forrest run"
to start jetty. The project is using the resources of the installed
forrest and can extend them arbitrarily.
In lenya we have to create new publications within the main webapp
because we have matches that are not using {variables:something}. When
we tried the integration, Joachim and I started in changing all matches
to {variables:something}. Sadly svn was not working and we could not
make a patch. I reckon that is the first step for lenya to become
copyless.
Joachim and I then created two jars for lenya. One that contained the
classes (the normal one) and another that included all resources under
{lenya-1.2.x}/build/webapp/lenya besides the pubs/. We then mounted
everything with resource://. That made it possible to keep the lenya
pubs/ within a cocoon instance *without* all other ressources (lenya
main webapp).
We actually got it working but could not get any content. IMO that is
because we didn't find all absolute or relative path that needed a
{variabel:something} and were pub specific. Sadly our PM reminded us on
the deadline of our project and we could not spend more time. ;-)
> > Actually I see lenya as a business service. I am still thinking about the interface
> > for the businessHelper plugin to connect to different business services. Maybe this
> > lists are best to discuss this.
> >
> > Thoughts welcome. ;-)
>
> As I mentioned in a previous mail I opted for this route. The CMS
> becomes a plugin to Forrest. At present I have the CMS running
> independently, but it could, theoretically be included in the plugin,
> assuming Jetty supports dynamic deployment of webapp.
>
> Doing it this way means that you can swap out the CMS or use multiple
> instances of it.
>
> Ross
:)
Like above written we tried this way and IMO it is possible but we need
to make lenya more copyless to achieve this goal Ross.
I created the dispatcher view in forrest because IMO with it will be
easy to integrate into lenya *and* forrest new business services via
business helper. IMO the view helper are pretty straight forward to
integrate into lenya (or any other cocoon based application). IMO via
the forrest view/viewHelper and the upcoming businessHelper plugins an
integration is possible in an efficient way.
Now wrapping everything up: IMO lenya should not depend on an installed
cocoon instance anymore but rather on an installed forrest instance. We
could use the forrest core and extend it by lenya specific plugins
instead of cocoon.
Why?
...because we (as in lenya) can concentrate on cms functionality and we
(as in forrest) can concentrate on input/output. Lets reuse as many code
from both projects as possible. It is highly inefficient to reinvent the
wheel all the time where we only need a good interface.
Now I hear some people from lenya scream saying that we will have JCR
integration and with that we do not have to worry anymore about input,
but IMO that is not true because JCR are far from solving all our
problems in regards to input. Besides that the output part of lenya is
more then week (we support only html by deault).
Another reason is the size of forrest (ca. 30 MB) in comparison to
cocoon (220 MB).
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Lenya and forrest integration
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-04-21 at 10:51 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Wed, 2005-04-20 at 14:41 -0400, Gregor J. Rothfuss wrote:
> >
> >>Thorsten Scherler wrote:
> ...
>
> >>from what i understand, forrest has a superior concept of 'resource
> >>types' (plugins in forrest lingo), pluggable sitemap components to
> >>handle rendering of new sorts of content.
> >>
> >
> >
> > In forrest we support three kind of plugins:
> > -input
> > -internal
> > -output
> >
> >
> >>lenya has a superior concept for bundling functionality (java, etc) with
> >>the usecase framework.
> >
> >
> > Actually I would like to have both concepts (bundling functionality and resource types)
> > together. Lets each project concentrate on what is best on and have an interface connect
> > them both. It should be working in forrest and lenya via plugins (lenya2forrest)
> > and usecases (forrest2lenya).
>
> Forrest Plugins can bundle extra functionality into Forrest (Java etc.)
> Basically, anything that can be done in Cocoon can be done in Forrest
> since Forrest is a Cocoon application (of course this is also true of
> Lenya).
>
> I have (almost) automated the conversion of Cocoon Blocks into Forrest
> plugins. I'm just stuck on how to embed extensions to the web.xml file.
> This is a problem that Cocoon will have to address as they work towards
> "real blocks", so I'm waiting for them rather than doing it alone.
>
All this work we (as in lenya) do not have to do again but we *could*
use it *if* we (as in lenya) decide to find a way to allow forrest
plugins to be mounted in lenya.
Like I said above forrest works with
-input
-internal
-output
plugins.
The plugin concept is quite easy to understand as shown as follow, it is
a simple mount in the main sitemap.xmap of forrest (found in
{forrest-trunk}/main/webapp/sitemap.xmap).
<!--This allows project specific sitemap's that can override some or
all matches of this sitemap -->
<map:pipeline internal-only="false">
<map:select type="exists">
<map:when test="{project:sitemap}">
<map:mount uri-prefix="" src="{project:sitemap}"
check-reload="yes"
pass-through="true"/>
</map:when>
</map:select>
</map:pipeline>
<!--This allows to override all internal specific matches by a plugin-->
<map:pipeline internal-only="false">
<map:select type="exists">
<map:when test="{project:temp-dir}/internal.xmap">
<map:mount uri-prefix="" src="{project:temp-dir}/internal.xmap"
check-reload="yes" pass-through="true"/>
</map:when>
</map:select>
</map:pipeline>
Like I said in my other mail *one* big advantage of forrest over lenya
is that it is working *copyless* this makes it possible to create a
project (forrest seed) anywhere on the file system and run "forrest run"
to start jetty. The project is using the resources of the installed
forrest and can extend them arbitrarily.
In lenya we have to create new publications within the main webapp
because we have matches that are not using {variables:something}. When
we tried the integration, Joachim and I started in changing all matches
to {variables:something}. Sadly svn was not working and we could not
make a patch. I reckon that is the first step for lenya to become
copyless.
Joachim and I then created two jars for lenya. One that contained the
classes (the normal one) and another that included all resources under
{lenya-1.2.x}/build/webapp/lenya besides the pubs/. We then mounted
everything with resource://. That made it possible to keep the lenya
pubs/ within a cocoon instance *without* all other ressources (lenya
main webapp).
We actually got it working but could not get any content. IMO that is
because we didn't find all absolute or relative path that needed a
{variabel:something} and were pub specific. Sadly our PM reminded us on
the deadline of our project and we could not spend more time. ;-)
> > Actually I see lenya as a business service. I am still thinking about the interface
> > for the businessHelper plugin to connect to different business services. Maybe this
> > lists are best to discuss this.
> >
> > Thoughts welcome. ;-)
>
> As I mentioned in a previous mail I opted for this route. The CMS
> becomes a plugin to Forrest. At present I have the CMS running
> independently, but it could, theoretically be included in the plugin,
> assuming Jetty supports dynamic deployment of webapp.
>
> Doing it this way means that you can swap out the CMS or use multiple
> instances of it.
>
> Ross
:)
Like above written we tried this way and IMO it is possible but we need
to make lenya more copyless to achieve this goal Ross.
I created the dispatcher view in forrest because IMO with it will be
easy to integrate into lenya *and* forrest new business services via
business helper. IMO the view helper are pretty straight forward to
integrate into lenya (or any other cocoon based application). IMO via
the forrest view/viewHelper and the upcoming businessHelper plugins an
integration is possible in an efficient way.
Now wrapping everything up: IMO lenya should not depend on an installed
cocoon instance anymore but rather on an installed forrest instance. We
could use the forrest core and extend it by lenya specific plugins
instead of cocoon.
Why?
...because we (as in lenya) can concentrate on cms functionality and we
(as in forrest) can concentrate on input/output. Lets reuse as many code
from both projects as possible. It is highly inefficient to reinvent the
wheel all the time where we only need a good interface.
Now I hear some people from lenya scream saying that we will have JCR
integration and with that we do not have to worry anymore about input,
but IMO that is not true because JCR are far from solving all our
problems in regards to input. Besides that the output part of lenya is
more then week (we support only html by deault).
Another reason is the size of forrest (ca. 30 MB) in comparison to
cocoon (220 MB).
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Lenya and forrest integration
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Wed, 2005-04-20 at 14:41 -0400, Gregor J. Rothfuss wrote:
>
>>Thorsten Scherler wrote:
...
>>from what i understand, forrest has a superior concept of 'resource
>>types' (plugins in forrest lingo), pluggable sitemap components to
>>handle rendering of new sorts of content.
>>
>
>
> In forrest we support three kind of plugins:
> -input
> -internal
> -output
>
>
>>lenya has a superior concept for bundling functionality (java, etc) with
>>the usecase framework.
>
>
> Actually I would like to have both concepts (bundling functionality and resource types)
> together. Lets each project concentrate on what is best on and have an interface connect
> them both. It should be working in forrest and lenya via plugins (lenya2forrest)
> and usecases (forrest2lenya).
Forrest Plugins can bundle extra functionality into Forrest (Java etc.)
Basically, anything that can be done in Cocoon can be done in Forrest
since Forrest is a Cocoon application (of course this is also true of
Lenya).
I have (almost) automated the conversion of Cocoon Blocks into Forrest
plugins. I'm just stuck on how to embed extensions to the web.xml file.
This is a problem that Cocoon will have to address as they work towards
"real blocks", so I'm waiting for them rather than doing it alone.
> Actually I see lenya as a business service. I am still thinking about the interface
> for the businessHelper plugin to connect to different business services. Maybe this
> lists are best to discuss this.
>
> Thoughts welcome. ;-)
As I mentioned in a previous mail I opted for this route. The CMS
becomes a plugin to Forrest. At present I have the CMS running
independently, but it could, theoretically be included in the plugin,
assuming Jetty supports dynamic deployment of webapp.
Doing it this way means that you can swap out the CMS or use multiple
instances of it.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Lenya and forrest integration
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2005-04-22 at 11:09 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Thu, 2005-04-21 at 21:59 -0400, Gregor J. Rothfuss wrote:
> >
...
> >>i am not sure if i like all these config files and formats. looks a bit
> >>like 'programming by config file' to me.
> >
> >
> > That is not programming! It is a configuration of components.
> > I like it very much because I want to develop components that I can
> > easily reuse *without* copy and paste and afterward changing 1 line of
> > code.
>
> This statement is even more true if these config files are automatically
> generated, which will be the case in the vast majority of use cases.
> Only power users will want to change default behaviour, and even then a
> tool could easily be provided to allow this to be done through form filling.
:)
I notice that you *really* understand what I am trying to do. ;-)
The tool (for views) you are referring to has the code name
"corium". ;-) Actually in old mails I referred to corium as what now is
the view/viewHelper plugin combination. Freely create a html-skeleton
and imitate e.g. css-zen-garden skeleton.
Anyway, corium should become a tool to create/manipulate views via a
web-interface. In my head there is the idea to create a flow that will
get the default.fv or the page specific view and then manipulate this
view via cforms and save it again. It should be very easy because
forrest is working copyless (praise the inventor of it). ;-)
Before we actually can start the work on it we need to finish the view
concept after the 0.7 release. The mayor missing part are the business
helper. I am still thinking of an abstract way to allow any business
service to connect. To consulate the forrest business service is not a
problem but it has to go beyond that.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Lenya and forrest integration
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Thu, 2005-04-21 at 21:59 -0400, Gregor J. Rothfuss wrote:
>
>>Thorsten Scherler wrote:
>>
>>
>>>A view will be configured by a config file which basically contains the
>>>following tags (it is still evolving):
>>>
>>><forrest:view type="xhtml">
>>> <forrest:css url="default.css"/>
>>> <forrest:contract name="meta"/>
>>> <forrest:hook name="container">
>>> <!--the following tags are not implement yet but will give the idea ;-)-->
>>> <forrest:contract name="deleteUser" nugget="lenya:usecase">
>>> <lenya:usecase name="deleteUser"/>
>>> </forrest:contract>
>>> <!--
>>> In forrest that will invoke a businessHelper that connects a lenya usecase
>>> and stores the result of the usecase (in forrest terms: nugget)
>>> in the presentation model. This part of the presentation model will be
>>> transformed by a forrest:contract (fbit) with the same name.
>>> -->
>>> <forrest:contract name="feedback"/>
>>> </forrest:hook />
>>></forrest:view>
>>>
>>>The view tag's @type determines the final output format. The idea is to
>>>configure different output formats within a forrest:views. That means a
>>>forrest:views can contain n different "forrest:view" configurations for
>>>n different formats.
>>
>>i am not sure if i like all these config files and formats. looks a bit
>>like 'programming by config file' to me.
>
>
> That is not programming! It is a configuration of components.
> I like it very much because I want to develop components that I can
> easily reuse *without* copy and paste and afterward changing 1 line of
> code.
This statement is even more true if these config files are automatically
generated, which will be the case in the vast majority of use cases.
Only power users will want to change default behaviour, and even then a
tool could easily be provided to allow this to be done through form filling.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Lenya and forrest integration
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Thu, 2005-04-21 at 21:59 -0400, Gregor J. Rothfuss wrote:
>
>>Thorsten Scherler wrote:
>>
>>
>>>A view will be configured by a config file which basically contains the
>>>following tags (it is still evolving):
>>>
>>><forrest:view type="xhtml">
>>> <forrest:css url="default.css"/>
>>> <forrest:contract name="meta"/>
>>> <forrest:hook name="container">
>>> <!--the following tags are not implement yet but will give the idea ;-)-->
>>> <forrest:contract name="deleteUser" nugget="lenya:usecase">
>>> <lenya:usecase name="deleteUser"/>
>>> </forrest:contract>
>>> <!--
>>> In forrest that will invoke a businessHelper that connects a lenya usecase
>>> and stores the result of the usecase (in forrest terms: nugget)
>>> in the presentation model. This part of the presentation model will be
>>> transformed by a forrest:contract (fbit) with the same name.
>>> -->
>>> <forrest:contract name="feedback"/>
>>> </forrest:hook />
>>></forrest:view>
>>>
>>>The view tag's @type determines the final output format. The idea is to
>>>configure different output formats within a forrest:views. That means a
>>>forrest:views can contain n different "forrest:view" configurations for
>>>n different formats.
>>
>>i am not sure if i like all these config files and formats. looks a bit
>>like 'programming by config file' to me.
>
>
> That is not programming! It is a configuration of components.
> I like it very much because I want to develop components that I can
> easily reuse *without* copy and paste and afterward changing 1 line of
> code.
This statement is even more true if these config files are automatically
generated, which will be the case in the vast majority of use cases.
Only power users will want to change default behaviour, and even then a
tool could easily be provided to allow this to be done through form filling.
Ross
Re: Lenya and forrest integration
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-04-21 at 21:59 -0400, Gregor J. Rothfuss wrote:
> Thorsten Scherler wrote:
>
> > A view will be configured by a config file which basically contains the
> > following tags (it is still evolving):
> >
> > <forrest:view type="xhtml">
> > <forrest:css url="default.css"/>
> > <forrest:contract name="meta"/>
> > <forrest:hook name="container">
> > <!--the following tags are not implement yet but will give the idea ;-)-->
> > <forrest:contract name="deleteUser" nugget="lenya:usecase">
> > <lenya:usecase name="deleteUser"/>
> > </forrest:contract>
> > <!--
> > In forrest that will invoke a businessHelper that connects a lenya usecase
> > and stores the result of the usecase (in forrest terms: nugget)
> > in the presentation model. This part of the presentation model will be
> > transformed by a forrest:contract (fbit) with the same name.
> > -->
> > <forrest:contract name="feedback"/>
> > </forrest:hook />
> > </forrest:view>
> >
> > The view tag's @type determines the final output format. The idea is to
> > configure different output formats within a forrest:views. That means a
> > forrest:views can contain n different "forrest:view" configurations for
> > n different formats.
>
> i am not sure if i like all these config files and formats. looks a bit
> like 'programming by config file' to me.
That is not programming! It is a configuration of components.
I like it very much because I want to develop components that I can
easily reuse *without* copy and paste and afterward changing 1 line of
code.
The format is chosen not to be limited again only on forrest or lenya. I
am sick of having multiple tools doing similar things and I have to find
out the way they work. With a common config file I do not care about the
underlying implementation.
The idea is to program your own contract implementation without having
to copy and paste (like it is the preferred method in lenya land) a xsl
and finally just changing a couple of lines.
IMO lenya has to follow forrests "copyless" approach. It cannot be that
if I change a xsl I have to rebuild the app.
That is leading the creation of cocoon in the first place to an absurd.
It was created to change xsl's, hit refresh on the browser and the
changes are there.
Now you will say that is as well possible, yeah right, in the build, but
I am a dev, it has to work also in the src (like it to in forrest).
The views concept is copyless! It is a configuring file for components.
...and IMO configuring is better then programming, why should I repeat
implementing the same code over and over again. Think about our user!
Copyless is the future.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Lenya and forrest integration
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-04-21 at 21:59 -0400, Gregor J. Rothfuss wrote:
> Thorsten Scherler wrote:
>
> > A view will be configured by a config file which basically contains the
> > following tags (it is still evolving):
> >
> > <forrest:view type="xhtml">
> > <forrest:css url="default.css"/>
> > <forrest:contract name="meta"/>
> > <forrest:hook name="container">
> > <!--the following tags are not implement yet but will give the idea ;-)-->
> > <forrest:contract name="deleteUser" nugget="lenya:usecase">
> > <lenya:usecase name="deleteUser"/>
> > </forrest:contract>
> > <!--
> > In forrest that will invoke a businessHelper that connects a lenya usecase
> > and stores the result of the usecase (in forrest terms: nugget)
> > in the presentation model. This part of the presentation model will be
> > transformed by a forrest:contract (fbit) with the same name.
> > -->
> > <forrest:contract name="feedback"/>
> > </forrest:hook />
> > </forrest:view>
> >
> > The view tag's @type determines the final output format. The idea is to
> > configure different output formats within a forrest:views. That means a
> > forrest:views can contain n different "forrest:view" configurations for
> > n different formats.
>
> i am not sure if i like all these config files and formats. looks a bit
> like 'programming by config file' to me.
That is not programming! It is a configuration of components.
I like it very much because I want to develop components that I can
easily reuse *without* copy and paste and afterward changing 1 line of
code.
The format is chosen not to be limited again only on forrest or lenya. I
am sick of having multiple tools doing similar things and I have to find
out the way they work. With a common config file I do not care about the
underlying implementation.
The idea is to program your own contract implementation without having
to copy and paste (like it is the preferred method in lenya land) a xsl
and finally just changing a couple of lines.
IMO lenya has to follow forrests "copyless" approach. It cannot be that
if I change a xsl I have to rebuild the app.
That is leading the creation of cocoon in the first place to an absurd.
It was created to change xsl's, hit refresh on the browser and the
changes are there.
Now you will say that is as well possible, yeah right, in the build, but
I am a dev, it has to work also in the src (like it to in forrest).
The views concept is copyless! It is a configuring file for components.
...and IMO configuring is better then programming, why should I repeat
implementing the same code over and over again. Think about our user!
Copyless is the future.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Lenya and forrest integration
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Thorsten Scherler wrote:
> A view will be configured by a config file which basically contains the
> following tags (it is still evolving):
>
> <forrest:view type="xhtml">
> <forrest:css url="default.css"/>
> <forrest:contract name="meta"/>
> <forrest:hook name="container">
> <!--the following tags are not implement yet but will give the idea ;-)-->
> <forrest:contract name="deleteUser" nugget="lenya:usecase">
> <lenya:usecase name="deleteUser"/>
> </forrest:contract>
> <!--
> In forrest that will invoke a businessHelper that connects a lenya usecase
> and stores the result of the usecase (in forrest terms: nugget)
> in the presentation model. This part of the presentation model will be
> transformed by a forrest:contract (fbit) with the same name.
> -->
> <forrest:contract name="feedback"/>
> </forrest:hook />
> </forrest:view>
>
> The view tag's @type determines the final output format. The idea is to
> configure different output formats within a forrest:views. That means a
> forrest:views can contain n different "forrest:view" configurations for
> n different formats.
i am not sure if i like all these config files and formats. looks a bit
like 'programming by config file' to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Lenya and forrest integration
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Wed, 2005-04-20 at 14:41 -0400, Gregor J. Rothfuss wrote:
>
>>Thorsten Scherler wrote:
...
>>from what i understand, forrest has a superior concept of 'resource
>>types' (plugins in forrest lingo), pluggable sitemap components to
>>handle rendering of new sorts of content.
>>
>
>
> In forrest we support three kind of plugins:
> -input
> -internal
> -output
>
>
>>lenya has a superior concept for bundling functionality (java, etc) with
>>the usecase framework.
>
>
> Actually I would like to have both concepts (bundling functionality and resource types)
> together. Lets each project concentrate on what is best on and have an interface connect
> them both. It should be working in forrest and lenya via plugins (lenya2forrest)
> and usecases (forrest2lenya).
Forrest Plugins can bundle extra functionality into Forrest (Java etc.)
Basically, anything that can be done in Cocoon can be done in Forrest
since Forrest is a Cocoon application (of course this is also true of
Lenya).
I have (almost) automated the conversion of Cocoon Blocks into Forrest
plugins. I'm just stuck on how to embed extensions to the web.xml file.
This is a problem that Cocoon will have to address as they work towards
"real blocks", so I'm waiting for them rather than doing it alone.
> Actually I see lenya as a business service. I am still thinking about the interface
> for the businessHelper plugin to connect to different business services. Maybe this
> lists are best to discuss this.
>
> Thoughts welcome. ;-)
As I mentioned in a previous mail I opted for this route. The CMS
becomes a plugin to Forrest. At present I have the CMS running
independently, but it could, theoretically be included in the plugin,
assuming Jetty supports dynamic deployment of webapp.
Doing it this way means that you can swap out the CMS or use multiple
instances of it.
Ross
Re: Lenya and forrest integration
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2005-04-20 at 14:41 -0400, Gregor J. Rothfuss wrote:
> Thorsten Scherler wrote:
>
> > my customer wants to have forrest in lenya (or vice versa). :)
> > Lenya is officially supporting 2.1.6 (but 2.1.7 is working fine).
> > Forrest is using 2.2-dev.
>
> 1.2.3 and trunk require 2.1.7
>
> i'd think cocoon 2.2 would work too after we take the new cocoon.xconf
> format (with includes) into account in the build process. also, there
> might be some minor flowscript issues to work out, but otherwise i'd
> expect it to work.
>
> > What do both lists think how to overcome this problem?
>
> we discussed whether to move trunk to cocoon trunk, but decided not to
> do so for now. there were some noises on the cocoon list recently about
> getting a 2.2 release out soon, which would help.
>
My +1 for reconsidering the move under the above mentioned circumstances
to 2.2 (at least for trunk).
> > I reckon I have to change the dir structure from either lenya or forrest
> > to make the forrest project files editable within lenya. Which app would
> > be best to "learn" the other site structure.
>
> from what i understand, forrest has a superior concept of 'resource
> types' (plugins in forrest lingo), pluggable sitemap components to
> handle rendering of new sorts of content.
>
> lenya has a superior concept for bundling functionality (java, etc) with
> the usecase framework.
>
> didn't you want to work on integrating forrest plugins into lenya?
>
:) I will do as soon I get wrapped up the view concept in forrest.
http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/org.apache.forrest.plugin.view/
http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/org.apache.forrest.plugin.viewHelper/
This is the first prototype implementation of a dispatcher view for
forrest. I hope to integrate this concept into lenya as well. The idea
is to easily have different page views for certain pages (e.g.
index.html will be rendered differently then other pages).
Abstract of the docu (with some modifications in the code example!):
Together with the ViewHelper and the BusinessHelper (to be implemented)
plugin this plugin is following the DispatcherView pattern [1] and
building the final view which will be delivered to the client. This
implementation follows exactly the pattern shown on corej2eepatterns.com
[2]
A view will be configured by a config file which basically contains the
following tags (it is still evolving):
<forrest:view type="xhtml">
<forrest:css url="default.css"/>
<forrest:contract name="meta"/>
<forrest:hook name="container">
<!--the following tags are not implement yet but will give the idea ;-)-->
<forrest:contract name="deleteUser" nugget="lenya:usecase">
<lenya:usecase name="deleteUser"/>
</forrest:contract>
<!--
In forrest that will invoke a businessHelper that connects a lenya usecase
and stores the result of the usecase (in forrest terms: nugget)
in the presentation model. This part of the presentation model will be
transformed by a forrest:contract (fbit) with the same name.
-->
<forrest:contract name="feedback"/>
</forrest:hook />
</forrest:view>
The view tag's @type determines the final output format. The idea is to
configure different output formats within a forrest:views. That means a
forrest:views can contain n different "forrest:view" configurations for
n different formats.
In short: x outputs formats, one config. :)
> > What do both projects think which one should become the main app (lenya
> > or forrest)?
>
> that's a funny question :)
>
;-)
>
> afaik forrest has no workflow, user management etc, so if you need
> those, the answer would be pretty clear.
>
I guess I should say lenya, ;-) but everything you just mentioned could be or is already
re-factored to a lenya plugin (usecase) in 1.4.
> from what i understand, forrest has a superior concept of 'resource
> types' (plugins in forrest lingo), pluggable sitemap components to
> handle rendering of new sorts of content.
>
In forrest we support three kind of plugins:
-input
-internal
-output
>
> lenya has a superior concept for bundling functionality (java, etc) with
> the usecase framework.
Actually I would like to have both concepts (bundling functionality and resource types)
together. Lets each project concentrate on what is best on and have an interface connect
them both. It should be working in forrest and lenya via plugins (lenya2forrest)
and usecases (forrest2lenya).
I wrote above:
"Together with the ViewHelper and the BusinessHelper
(to be implemented) plugin this plugin is following the DispatcherView pattern"
Actually I see lenya as a business service. I am still thinking about the interface
for the businessHelper plugin to connect to different business services. Maybe this
lists are best to discuss this.
Thoughts welcome. ;-)
>
> > Another more lenya specific question is the usage of 1.4. for the
> > integration. We decided to release 1.4 within 2-3 month, do we consider
> > this release as (relatively) stable?
>
> definitely do this on 1.4, since 1.2 does not have the usecase framework
>
Yeah, I thought so, but is it ready for a production system?
salu2
[1] http://java.sun.com/j2ee/patterns/DispatcherView.html
[2] http://corej2eepatterns.com/Patterns2ndEd/DispatcherView.htm
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Lenya and forrest integration
Posted by Ross Gardler <rg...@apache.org>.
Andreas Hartmann wrote:
> Ross Gardler wrote:
>
>> Gregor J. Rothfuss wrote:
>>
>>> Thorsten Scherler wrote:
>>
>>
>>
>> ...
>>
>>>> What do both projects think which one should become the main app (lenya
>>>> or forrest)?
>>>
>>>
>>>
>>>
>>> that's a funny question :)
>>>
>>> afaik forrest has no workflow, user management etc, so if you need
>>> those, the answer would be pretty clear.
>>
>>
>>
>> I think the question is "should Lenya become a Forrest plugin or
>> vice-versa". This is an important question because whichever is the
>> "main app" would have the ability to override functionality of the other.
>>
>> For my case I chose for the CMS to run separately from the publication
>> engine (Forrest) and only integrate at the publication level. This
>> makes the CMS a plugin for Forrest. The advantage of this way around
>> is that it allows multiple CMS systems to provide content for multiple
>> Forrest based sites.
>>
>> On the other hand, if Forrest is embedded into Lenya as a presentation
>> engine I suspect you would only be able to use a single instance of
>> Lenya as a source for content. Whether this is a disadvantage or not
>> depends on the use case, for my own it is a problem.
>
>
> If you need WYSIWYG browsing and editing in Lenya, I guess you'll have
> to use Forrest (or parts of it) as a presentation engine. Actually it was
> a design goal of Lenya to support (virtually) arbitrary Cocoon-based sites
> as presentation engines, but of course this by far not possible.
>
> My first idea would be to create a Forrest publication template [1]
> which would support at least a subset of Forrest's rendering possibilities
> and allow to add and edit documents (document-vXX, faq-vXX etc.).
>
> The question is how to get Forrest to work as a Lenya publication,
> not as a webapp on its own. Yesterday I did some experiments, but ran
> into problems because the file system paths are not compatible. I'll
> do some more investigation when I find the time.
I believe you are going about this the wrong way. Why tie Forrest into
Lenya or vice-versa? You will make maintenance difficult since your will
have to keep the integration in synch on both sides.
What do I suggest incited? Well, your second proposal actually:
> Another way would be a publication template with a custom rendering
> engine able to present Forrest documents in a basic, stripped-down
> way, together with a simple navigation tree. That would probably be
> sufficient to maintain a documentation website.
> The drawback would be that you don't have WYSIWYG and miss some
> features, the advantage is the low implementation entry barrier.
Have Forrest request an unskinned version of the document to be
published from Lenya, and only use Forrest as a *publication* engine, do
not try and integrate it into the editing infrastructure. Stick with
what you have from the editing perspective. It is possible to embed
editors into Forrest pages, but why bother? The editor does not want to
see the end result, they want the cleanest simplest editing environment.
This environment should be optimised for their needs. Lenya does a great
job of this already.
How do you get from a page in Forrest to the edit screen in Lenya. Do it
the simple way, provide an edit link on the page that takes you back to
the Lenya editing environment.
The advantages of doing things this way is that you can publish content
from multiple, distributed Lenya repositories as well as from multiple
other types of repositories, Daisy integration is underway and we may
have someone working on Slide integration soon.
The way to achieve this is through locationmaps. See
http://marc.theaimsgroup.com/?l=forrest-dev&m=111770641922349&w=2 for an
outline of how this works.
With respect to the disadvantages you highlight. You don't have WYSIWYG
but you do get WYSIWYM (M = mean), which in my opinion is far more
important. Your other disadvantage is "you miss some features". what are
they, if they are common CMS features then we should find a way of
getting them into a common repository plugin.
Ross
>
> [1] http://lenya.apache.org/1_4/reference/publication-templating/index.html
>
> -- Andreas
>
>
>
>
Re: Lenya and forrest integration
Posted by Andreas Hartmann <an...@apache.org>.
Ross Gardler wrote:
> Gregor J. Rothfuss wrote:
>
>> Thorsten Scherler wrote:
>
>
> ...
>
>>> What do both projects think which one should become the main app (lenya
>>> or forrest)?
>>
>>
>>
>> that's a funny question :)
>>
>> afaik forrest has no workflow, user management etc, so if you need
>> those, the answer would be pretty clear.
>
>
> I think the question is "should Lenya become a Forrest plugin or
> vice-versa". This is an important question because whichever is the
> "main app" would have the ability to override functionality of the other.
>
> For my case I chose for the CMS to run separately from the publication
> engine (Forrest) and only integrate at the publication level. This makes
> the CMS a plugin for Forrest. The advantage of this way around is that
> it allows multiple CMS systems to provide content for multiple Forrest
> based sites.
>
> On the other hand, if Forrest is embedded into Lenya as a presentation
> engine I suspect you would only be able to use a single instance of
> Lenya as a source for content. Whether this is a disadvantage or not
> depends on the use case, for my own it is a problem.
If you need WYSIWYG browsing and editing in Lenya, I guess you'll have
to use Forrest (or parts of it) as a presentation engine. Actually it was
a design goal of Lenya to support (virtually) arbitrary Cocoon-based sites
as presentation engines, but of course this by far not possible.
My first idea would be to create a Forrest publication template [1]
which would support at least a subset of Forrest's rendering possibilities
and allow to add and edit documents (document-vXX, faq-vXX etc.).
The question is how to get Forrest to work as a Lenya publication,
not as a webapp on its own. Yesterday I did some experiments, but ran
into problems because the file system paths are not compatible. I'll
do some more investigation when I find the time.
Another way would be a publication template with a custom rendering
engine able to present Forrest documents in a basic, stripped-down
way, together with a simple navigation tree. That would probably be
sufficient to maintain a documentation website.
The drawback would be that you don't have WYSIWYG and miss some
features, the advantage is the low implementation entry barrier.
[1] http://lenya.apache.org/1_4/reference/publication-templating/index.html
-- Andreas
Re: Lenya and forrest integration
Posted by Ross Gardler <rg...@apache.org>.
Gregor J. Rothfuss wrote:
> Thorsten Scherler wrote:
...
>> What do both projects think which one should become the main app (lenya
>> or forrest)?
>
>
> that's a funny question :)
>
> afaik forrest has no workflow, user management etc, so if you need
> those, the answer would be pretty clear.
I think the question is "should Lenya become a Forrest plugin or
vice-versa". This is an important question because whichever is the
"main app" would have the ability to override functionality of the other.
For my case I chose for the CMS to run separately from the publication
engine (Forrest) and only integrate at the publication level. This makes
the CMS a plugin for Forrest. The advantage of this way around is that
it allows multiple CMS systems to provide content for multiple Forrest
based sites.
On the other hand, if Forrest is embedded into Lenya as a presentation
engine I suspect you would only be able to use a single instance of
Lenya as a source for content. Whether this is a disadvantage or not
depends on the use case, for my own it is a problem.
Ross
Re: Lenya and forrest integration
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2005-04-20 at 14:41 -0400, Gregor J. Rothfuss wrote:
> Thorsten Scherler wrote:
>
> > my customer wants to have forrest in lenya (or vice versa). :)
> > Lenya is officially supporting 2.1.6 (but 2.1.7 is working fine).
> > Forrest is using 2.2-dev.
>
> 1.2.3 and trunk require 2.1.7
>
> i'd think cocoon 2.2 would work too after we take the new cocoon.xconf
> format (with includes) into account in the build process. also, there
> might be some minor flowscript issues to work out, but otherwise i'd
> expect it to work.
>
> > What do both lists think how to overcome this problem?
>
> we discussed whether to move trunk to cocoon trunk, but decided not to
> do so for now. there were some noises on the cocoon list recently about
> getting a 2.2 release out soon, which would help.
>
My +1 for reconsidering the move under the above mentioned circumstances
to 2.2 (at least for trunk).
> > I reckon I have to change the dir structure from either lenya or forrest
> > to make the forrest project files editable within lenya. Which app would
> > be best to "learn" the other site structure.
>
> from what i understand, forrest has a superior concept of 'resource
> types' (plugins in forrest lingo), pluggable sitemap components to
> handle rendering of new sorts of content.
>
> lenya has a superior concept for bundling functionality (java, etc) with
> the usecase framework.
>
> didn't you want to work on integrating forrest plugins into lenya?
>
:) I will do as soon I get wrapped up the view concept in forrest.
http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/org.apache.forrest.plugin.view/
http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/org.apache.forrest.plugin.viewHelper/
This is the first prototype implementation of a dispatcher view for
forrest. I hope to integrate this concept into lenya as well. The idea
is to easily have different page views for certain pages (e.g.
index.html will be rendered differently then other pages).
Abstract of the docu (with some modifications in the code example!):
Together with the ViewHelper and the BusinessHelper (to be implemented)
plugin this plugin is following the DispatcherView pattern [1] and
building the final view which will be delivered to the client. This
implementation follows exactly the pattern shown on corej2eepatterns.com
[2]
A view will be configured by a config file which basically contains the
following tags (it is still evolving):
<forrest:view type="xhtml">
<forrest:css url="default.css"/>
<forrest:contract name="meta"/>
<forrest:hook name="container">
<!--the following tags are not implement yet but will give the idea ;-)-->
<forrest:contract name="deleteUser" nugget="lenya:usecase">
<lenya:usecase name="deleteUser"/>
</forrest:contract>
<!--
In forrest that will invoke a businessHelper that connects a lenya usecase
and stores the result of the usecase (in forrest terms: nugget)
in the presentation model. This part of the presentation model will be
transformed by a forrest:contract (fbit) with the same name.
-->
<forrest:contract name="feedback"/>
</forrest:hook />
</forrest:view>
The view tag's @type determines the final output format. The idea is to
configure different output formats within a forrest:views. That means a
forrest:views can contain n different "forrest:view" configurations for
n different formats.
In short: x outputs formats, one config. :)
> > What do both projects think which one should become the main app (lenya
> > or forrest)?
>
> that's a funny question :)
>
;-)
>
> afaik forrest has no workflow, user management etc, so if you need
> those, the answer would be pretty clear.
>
I guess I should say lenya, ;-) but everything you just mentioned could be or is already
re-factored to a lenya plugin (usecase) in 1.4.
> from what i understand, forrest has a superior concept of 'resource
> types' (plugins in forrest lingo), pluggable sitemap components to
> handle rendering of new sorts of content.
>
In forrest we support three kind of plugins:
-input
-internal
-output
>
> lenya has a superior concept for bundling functionality (java, etc) with
> the usecase framework.
Actually I would like to have both concepts (bundling functionality and resource types)
together. Lets each project concentrate on what is best on and have an interface connect
them both. It should be working in forrest and lenya via plugins (lenya2forrest)
and usecases (forrest2lenya).
I wrote above:
"Together with the ViewHelper and the BusinessHelper
(to be implemented) plugin this plugin is following the DispatcherView pattern"
Actually I see lenya as a business service. I am still thinking about the interface
for the businessHelper plugin to connect to different business services. Maybe this
lists are best to discuss this.
Thoughts welcome. ;-)
>
> > Another more lenya specific question is the usage of 1.4. for the
> > integration. We decided to release 1.4 within 2-3 month, do we consider
> > this release as (relatively) stable?
>
> definitely do this on 1.4, since 1.2 does not have the usecase framework
>
Yeah, I thought so, but is it ready for a production system?
salu2
[1] http://java.sun.com/j2ee/patterns/DispatcherView.html
[2] http://corej2eepatterns.com/Patterns2ndEd/DispatcherView.htm
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Lenya and forrest integration
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Thorsten Scherler wrote:
> my customer wants to have forrest in lenya (or vice versa). :)
> Lenya is officially supporting 2.1.6 (but 2.1.7 is working fine).
> Forrest is using 2.2-dev.
1.2.3 and trunk require 2.1.7
i'd think cocoon 2.2 would work too after we take the new cocoon.xconf
format (with includes) into account in the build process. also, there
might be some minor flowscript issues to work out, but otherwise i'd
expect it to work.
> What do both lists think how to overcome this problem?
we discussed whether to move trunk to cocoon trunk, but decided not to
do so for now. there were some noises on the cocoon list recently about
getting a 2.2 release out soon, which would help.
> I reckon I have to change the dir structure from either lenya or forrest
> to make the forrest project files editable within lenya. Which app would
> be best to "learn" the other site structure.
from what i understand, forrest has a superior concept of 'resource
types' (plugins in forrest lingo), pluggable sitemap components to
handle rendering of new sorts of content.
lenya has a superior concept for bundling functionality (java, etc) with
the usecase framework.
didn't you want to work on integrating forrest plugins into lenya?
> What do both projects think which one should become the main app (lenya
> or forrest)?
that's a funny question :)
afaik forrest has no workflow, user management etc, so if you need
those, the answer would be pretty clear.
> Another more lenya specific question is the usage of 1.4. for the
> integration. We decided to release 1.4 within 2-3 month, do we consider
> this release as (relatively) stable?
definitely do this on 1.4, since 1.2 does not have the usecase framework
Re: Lenya and forrest integration
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Thorsten Scherler wrote:
> my customer wants to have forrest in lenya (or vice versa). :)
> Lenya is officially supporting 2.1.6 (but 2.1.7 is working fine).
> Forrest is using 2.2-dev.
1.2.3 and trunk require 2.1.7
i'd think cocoon 2.2 would work too after we take the new cocoon.xconf
format (with includes) into account in the build process. also, there
might be some minor flowscript issues to work out, but otherwise i'd
expect it to work.
> What do both lists think how to overcome this problem?
we discussed whether to move trunk to cocoon trunk, but decided not to
do so for now. there were some noises on the cocoon list recently about
getting a 2.2 release out soon, which would help.
> I reckon I have to change the dir structure from either lenya or forrest
> to make the forrest project files editable within lenya. Which app would
> be best to "learn" the other site structure.
from what i understand, forrest has a superior concept of 'resource
types' (plugins in forrest lingo), pluggable sitemap components to
handle rendering of new sorts of content.
lenya has a superior concept for bundling functionality (java, etc) with
the usecase framework.
didn't you want to work on integrating forrest plugins into lenya?
> What do both projects think which one should become the main app (lenya
> or forrest)?
that's a funny question :)
afaik forrest has no workflow, user management etc, so if you need
those, the answer would be pretty clear.
> Another more lenya specific question is the usage of 1.4. for the
> integration. We decided to release 1.4 within 2-3 month, do we consider
> this release as (relatively) stable?
definitely do this on 1.4, since 1.2 does not have the usecase framework
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Lenya and forrest integration
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Wed, 2005-04-20 at 19:09 +0100, Ross Gardler wrote:
>
>>Thorsten Scherler wrote:
>>
>>>Sorry for the crosspost but it seems to be from interest for both
>>>lists. ;-)
>>>
>>>Hello devs,
>>>
>>>my customer wants to have forrest in lenya (or vice versa). :)
>>>
>>>The question that pops into to my head is the compatibility between the
>>>cocoon versions used by lenya/forrest.
>>>
>>>Lenya is officially supporting 2.1.6 (but 2.1.7 is working fine).
>>>Forrest is using 2.2-dev.
>>>
>>>Will I run into problems because of that?
>>
>>I don't know about that but...
>>
>>
>>>What do both lists think how to overcome this problem?
>>>
>>>I reckon I have to change the dir structure from either lenya or forrest
>>>to make the forrest project files editable within lenya. Which app would
>>>be best to "learn" the other site structure.
>>>
>>>What do both projects think which one should become the main app (lenya
>>>or forrest)?
>>
>>I looked into this some time back and decided that it was simply too
>>much effort to separate the various components of Lenya to allow it to
>>be cleanly integrated with Forrest (or vice-versa). At that time the
>>Lenya community were trying to make their system more modular, so things
>>may have changed. Furthermore, I am aware that you have a better
>>understanding of the Lenya internals than I do so perhaps you could do
>>what I was scared of attempting.
>>
>
>
> :) we just tried and it was looking pretty good till a certain point. We
> could just spend a day on it because the deadline of the project. ...but
> we will do it again in the next couple of months. :)
Sounds very similar to my own experience.
>>Instead I decided to use Daisy. I'm currently building a plugin to allow
>>Daisy content to be included in a Forrest site. You can find the code in
>>the whiteboard.
>>
>
>
> I will have a look to learn from you code maybe I can just change some
> things to make it work for lenya. ;-)
Well this is the second iteration of the plugin. I have a fully working
version that is hacked together but I don't like many ways I have done
things. So this version should be a big improvement. What would be great
is if we can work out a best practice for this kind of integration. I
would love to be able to do it for many different CMS systems, including
a load of Wiki's.
Imagine the value/flexibility of a Wikipedia plugin, coupled with a
Daisys plugin, coupled with a Lenya plugin (see my other reply with
respect to which is the main app).
Ross
Re: Lenya and forrest integration
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2005-04-20 at 19:09 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > Sorry for the crosspost but it seems to be from interest for both
> > lists. ;-)
> >
> > Hello devs,
> >
> > my customer wants to have forrest in lenya (or vice versa). :)
> >
> > The question that pops into to my head is the compatibility between the
> > cocoon versions used by lenya/forrest.
> >
> > Lenya is officially supporting 2.1.6 (but 2.1.7 is working fine).
> > Forrest is using 2.2-dev.
> >
> > Will I run into problems because of that?
>
> I don't know about that but...
>
> > What do both lists think how to overcome this problem?
> >
> > I reckon I have to change the dir structure from either lenya or forrest
> > to make the forrest project files editable within lenya. Which app would
> > be best to "learn" the other site structure.
> >
> > What do both projects think which one should become the main app (lenya
> > or forrest)?
>
> I looked into this some time back and decided that it was simply too
> much effort to separate the various components of Lenya to allow it to
> be cleanly integrated with Forrest (or vice-versa). At that time the
> Lenya community were trying to make their system more modular, so things
> may have changed. Furthermore, I am aware that you have a better
> understanding of the Lenya internals than I do so perhaps you could do
> what I was scared of attempting.
>
:) we just tried and it was looking pretty good till a certain point. We
could just spend a day on it because the deadline of the project. ...but
we will do it again in the next couple of months. :)
In regards to the lenya internals I am now again on a project that is
build around lenya after 3 years. I still have some catching up to do
but I reckon I finally see a chance to do the integration within the
current project.
The 1.4 release of lenya will be one big step into the direction of real
modular components but it will at least take a couple of month till it
get out.
Further my client shares my opinion that he needs forrest within lenya.
One big seller actually is the view/viewHelper concept. ;-) I hope that
I am in luck and we can finish the work on the plugin and the
integration into lenya in a couple of months.
> Instead I decided to use Daisy. I'm currently building a plugin to allow
> Daisy content to be included in a Forrest site. You can find the code in
> the whiteboard.
>
I will have a look to learn from you code maybe I can just change some
things to make it work for lenya. ;-)
> So, if Daisy is a viable alternative to Lenya for you then perhaps I can
> save you some work ;-)
>
LOL cheers, but that is not an option. The customer is happy with lenya
(so am I).
...and I am a lenya committer. ;-)
> Ross
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Lenya and forrest integration
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Thorsten Scherler wrote:
>
>> Sorry for the crosspost but it seems to be from interest for both
>> lists. ;-)
>>
>> Hello devs,
>>
>> my customer wants to have forrest in lenya (or vice versa). :)
>>
>> The question that pops into to my head is the compatibility between the
>> cocoon versions used by lenya/forrest.
>>
>> Lenya is officially supporting 2.1.6 (but 2.1.7 is working fine).
>> Forrest is using 2.2-dev.
>>
>> Will I run into problems because of that?
>
>
> I don't know about that but...
Actually I do know about that. It *will* cause you problems as the xconf
include stuff is in 2.2-dev as is the sitemap pass through that enables
the plugins.
Ross
Re: Lenya and forrest integration
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> Sorry for the crosspost but it seems to be from interest for both
> lists. ;-)
>
> Hello devs,
>
> my customer wants to have forrest in lenya (or vice versa). :)
>
> The question that pops into to my head is the compatibility between the
> cocoon versions used by lenya/forrest.
>
> Lenya is officially supporting 2.1.6 (but 2.1.7 is working fine).
> Forrest is using 2.2-dev.
>
> Will I run into problems because of that?
I don't know about that but...
> What do both lists think how to overcome this problem?
>
> I reckon I have to change the dir structure from either lenya or forrest
> to make the forrest project files editable within lenya. Which app would
> be best to "learn" the other site structure.
>
> What do both projects think which one should become the main app (lenya
> or forrest)?
I looked into this some time back and decided that it was simply too
much effort to separate the various components of Lenya to allow it to
be cleanly integrated with Forrest (or vice-versa). At that time the
Lenya community were trying to make their system more modular, so things
may have changed. Furthermore, I am aware that you have a better
understanding of the Lenya internals than I do so perhaps you could do
what I was scared of attempting.
Instead I decided to use Daisy. I'm currently building a plugin to allow
Daisy content to be included in a Forrest site. You can find the code in
the whiteboard.
So, if Daisy is a viable alternative to Lenya for you then perhaps I can
save you some work ;-)
Ross