Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42EE20D3.8080309@apache.org>
Date: Mon, 01 Aug 2005 14:17:07 +0100
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: Quick evaluation of Cocoon Portal Engine as forrest:views
 implementation
References: <42ECF8BD.6040900@apache.org> <42EDD056.4090002@uidesign.de>
 <42EE0A74.60309@apache.org> <42EE1B48.9020107@apache.org>
 <42EE1B92.7000209@apache.org>
In-Reply-To: <42EE1B92.7000209@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

yes

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

Ross

[1] 
http://cocoon.apache.org/2.1/developing/portal/portal-block.html#Configuring+the+arrangement+of+the+defined+Coplets

[2]
http://cocoon.apache.org/2.1/developing/portal/portal-block.html#Create+a+new+skin+for+your+portal