forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Date Sun, 31 Jul 2005 19:50:45 GMT
When you mean using "Cocoon Portlets rather then views" and dropping the
whole view implementation, then no. There is more to view then the scope
of portlets.  

Cocoon Portlets should be usable within the forrest:views *.fv as
forrest:contracts. The *.fv will be the meta configuration of all
included forrest:contracts. The idea is not to limit views (and
contracts) to a specific implementation. Cocoon portlets can be *one*
implementation but there should/could be as well other.

forrest:views is more a concept (interface) rather then an specific
implementation. The forrest:contracts that we have right now would be
another implementation besides portlets. ...but there should not become
necessarily portlets themselves like you suggest.

On Sun, 2005-07-31 at 17:13 +0100, Ross Gardler wrote: 
> 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.

Can the cocoon portal use CLI?

> 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 
> repositories)
> - clean and simple layout config
> - deep nesting is possible

My idea is to use forrest:views for producing [5] and I reckon that is a
great idea. I see [5] as implementation of our views. I mean
forrest:views are transformed into [5] when requested in a portal. 

A pdf document would not need a portal configuration and engine just
another implementation of views. The format independent concept of views
is the important point. 

I do not see the following advantages from the "Layout Definition" over

- clean and simple layout config
I consider forrest:views way simpler and cleaner (or at least not more
Having [5]:
<coplet id="personalize" position="1" number="1"> 
      <resource uri="financecoplet-personalize.xml"/>
      <content>..the coplet content...</content>

We have:
> <forrest:contract name="content-feeder">
>     <forrest:properties contract="content-feeder">
>       <forrest:property name="content-feeder"
> nugget="get.nugget.feeder">
>         <url>/feeds/somefeed.xml</url>
>       </forrest:property>
>     </forrest:properties>
> </forrest:contract>

I agree we can learn a lot of [5] but it should be seen as a portal
implementation of forrest:views. I can reuse a contract in a different
environment that not have to be based on Cocoon Portlets but I still can
use the same DSL configuration language to configure the environment. 

- deep nesting is possible
That is as well possible with forrest:views.

The main advantage of forrest:views is that is not limited to portlets.
x output format - one configuration. That is the slogan of

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

Not moved but write a transformation for forrest:views to [5].

> Coplets
> --------
> 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.

Actually the PMC agreed that forrest do not want to focus on being a
JSR-168 compliant portal. That is not our main focus but it could be
easily done via the forrest:views language *layer*. We can support
Cocoon portlet implementation via forrest:views but we still are open
for other implementation

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

IMO we should not do this because forrest is not a portal.

> Advantages that I see of coplets over forrest:contracts include:
> - simpler config

No, I do not see that they are simpler.

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

Yes that is very nice but they are only special contacts.

> Themes
> ------
> 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.

I have to have a closer look into this part, but I reckon Cocoon Portal
may consider cooperate on our configuration format (forrest:views). 

> 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.
> Conclusion
> ----------
> 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 
> feedback.

IMO we should not exclusively focus the development of forrest:views
onto cocoon portal. We have to cooperate the best we can. Following
David comment:
> I wonder if the way forward is an integration of portals
and our "views", i.e. the portal does some of the work
and our views does the rest.

It should be
"Using forrest:views for configuring Cocoon Portlets" and not like
suggested "Use Cocoon Portlets rather than views?".


> References
> ----------
> [1] 
> [2]
> [3]
> [4]


"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message