Re: Lenya and forrest integration

[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

[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
> 
> 
> 
>