forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Date Mon, 01 Aug 2005 13:17:07 GMT
> Nicola Ken Barozzi wrote:
>  > Johannes Schaefer wrote:
>  > ...
>  >
>  >>* The portal uses a configuration hierarchy:
>  >>  1. define coplets
>  >>  2. define instances
>  >>     (may use coplets multiple times)
>  >>  3. define the layout
>  >
>  >
>  > How does it define layout?

Full details in [1]. In short you define a series of rows and columns. 
As both myself and Johannes observed the potential for theming in the 
Portal Engine is limited, this rows/columns concept is one cause of 
this. Forrest:views is far superior in its theming. The portal engine 
skin system looks very similar to our "old fashioned" skinning (see [2])

I think that we would want to replace the skinning system with the 
forrest:views approach (disclaimer: I have not yet discussed this with 
any Portal devs and have not looked in detail at how realistic this is)

>  > One more thing that comes to mind... Cocoon portal-coplets seem like a
>  > perfect way to define what /content/ is to be in a page.

Yes, this is the main reason I like the idea of using the portal engine 
as a forrest:views implementation. Coplets are not *just* portlets. They 
can be JSR-168 portlets (WSRP coming soon) but they can also be a java 
class, an XML file, a XSL template or pretty much anything you want them 
to be.

forrest:contracts are (at present) only XSL transformations. This does 
not allow us to utilise the full power of Cocoon in contracts.

For example when a contract defines /content/ (i.e. the feeder contract) 
it uses an XSL template to insert an xi:include into the document. This 
is then processed by Cocoon to include the content. In other words it is 
*implemented* in exactly the same way as if we insert xi:include 
directly into the src document. Since Cocoon cannot cache xi:include 
content this creates a major performance problem.

>  > It seems to me that it starts lacking when I need to insert pieces of
>  > functionality, as they may have to touch the whole page and filter it.
>  >
>  > IOW a portal is an excellent - user configurable - <xinclude> mechanism,
>  > but views are not only about that.


>  > I mean, views are basically a page-templating system. Can a portal be
>  > defined as a page-templating system?

I believe so, furthermore, I believe utilising the portal engine will 
save us much development effort (I repeat my disclaimer, I have not yet 
looked under the hood or played with the code - this is a *belief* not 
an statement of fact).

>  > Still many questions and no good answer...

Lets keep discussing




View raw message