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
