forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Date Sun, 31 Jul 2005 16:13:49 GMT
This is only a very quick evaluation of the Cocoon Portal Engine as a 
possible forrest:views implementation. It is in no way exhaustive and I 
have not done any real experiments with code. This last point is *very* 
important. I have not evaluated how practicle it is to utilise the 
Cocoon portal engine to create a *static* rendering of a Forrest site.

I've been working from the Portal demo in Cocoon [1], Carstens slides 
form ApacheConEU2005 [2] and the portal documentation [3]

Layout Definition

Nearest equivalent in forrest:views is the *.fv files.

The portal engine excels here. It provides a web based interface for 
defining your layout, this can be used in a dynamic environment to allow 
users to have their own unique layout.

Advantages I see of the portal engine over forrest:views include:

- tried and tested config language
- configs can be stored anywhere (such as XML files, LDAP or other 
- clean and simple layout config
- deep nesting is possible

What I am not sure about at this stage is if we can have per directory, 
per document or per doctype layout definitions. However, since the 
layout is retrieved from a standard Cocoon pipeline I doubt it would be 
difficult to move the forrest:views solution into the portlet engine.I 
note one of the bullets in Carstens presentation was "Layout engine can 
be used without additional Portal functionality" - need to investigate this.


Nearest equivalent in forrest:views is forrest:templates

The portal engine is JSR-168 compliant (the demo includes the pluto [4] 
test suite of portlets). WSRP support is "coming real soon". This gives 
us access to a growing number of stnadards based portlets.

Looking at how a portlet is defined it should be trivial to migrate our 
30+ contracts to portlets.

Advantages that I see of coplets over forrest:contracts include:

- simpler config
- individual buffering of coplet content (prevents the whole page 
breaking if an individual coplet is broken)
- individual error handling for each coplet
- configrable timeouts for coplet data
- configuration overriding capabilities
- configured rendering of individual coplets (i.e. create different 
formats from a single coplet instance)
- uses placeholders for coplets - in a dynamic environment page will 
render even if still waiting for some coplet data


This looks like the weakest part of the Cocoon Portal engine and where 
forrest:views can improve things considerably. At present much of the 
style information is embedded in the resulting HTML page. This is not 
acceptable for a Forrest solution.

Most of the style information is embedded within the layout definition 
file. I think we would have to extend the portal engine to have 
behaviour like that provided by forrest:hooks so that the structure of 
the resulting portal page can be easily skinned by CSS. Looking at the 
current layout config files this does not look like it is complex 
(remember this is only a cursory evaluation, not a proposal at this stage)

NOTE: there is a bullet in one of Carstens slides that says "change the 
skin". I've not discovered more about this yet.

Tools Framework

This is an area that is still under development, however, it is a stated 
goal of the project to create a tools framework for managing portals. It 
is likely that this framework could be used to build customer focussed 
tools for developing forrest sites.


My cursory evaluation makes me think that we should eplore this further, 
but before I spend more time on this I would like to have some community 






View raw message