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)
