forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Date Tue, 02 Aug 2005 16:29:14 GMT
Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
> 
>>>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)
> 
> 
> Another portal engine with it's theming support explained:
> 
>   http://www.javalobby.org/articles/liferay/

This site clearly illustrates the strength of forrest:views over a 
portal layout descriptor. Notice that the layout of all the pages are 
the same, it is only the look and feel that has changed. Now read on...

>>> > 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.
> 
> ...
> 
>>> > 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).
> 
> 
> IMV a portal is a dynamic content *aggregator*, rather than a templating
> system, and in this role it will certainly help our efforts.

Yes, which is exactly the purpose of the *views* part of forrest:views, 
i.e. strip away away the theme stuff.

> Here I read: http://portals.apache.org/jetspeed-2/psml.html
> 
>  "page layout is not a part of the Java Portlet Standard API"

What isn't apparent from your single line extract is that this document 
describes the page structure language used by jetspeed. In other words 
it describes their equivalent to the *.fv files.

The big difference between portal layout languages and the forrest:views 
language is that the portal languages define a *fixed* layout whereas 
forrest:views define a page structure rather than a layout. This enables 
  a further separation of concerns:

- the look and feel (the theme) of a forrest:views defined page to be 
under the control of the layout designer (the CSS designer for HTML output)

- the definition of the source of content to be aggregated in a page is 
under the control of the site designer

- the definition of actual content is under the control of the content 
editor

> Now I understand where views can mutually fit in.
> 
> Some extra info on Jetspeed layout and decorators:
> 
> http://portals.apache.org/jetspeed-2/layouts.html
> http://portals.apache.org/jetspeed-2/decorators.html

Yes - lets play a game, can everyone spot the similarities with 
forrest:views?

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

Ross

Mime
View raw message