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
