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
