Portal: Configuration

This document describes the use and configuration of the (new) cocoon portal that you can find in the "portal" block. (Don't mix this with the older portal version that you can find in the "portal-fw" block.)

Important parts of the Cocoon Portal

TBD

How is a portal page created by Cocoon?

TBD

I want to build my own portal! An approach

TBD

The configuration of a coplet is done in several steps that are outlined in the next chapters.

Configuring Coplets

Configuring coplets is like defining a class and creating their instances. So in fact, you define the available coplets (= classes) and each portal view gets some instances of these coplets.

Available Coplet Types

Before you can define your available coplets, you have to define the available coplet types, or the so called coplet base data. The current sample contains an XML document for this:

...
<coplets>
   <coplet-base-data id="URICoplet">
      <coplet-adapter>uri</coplet-adapter>
   </coplet-base-data>
</coplets>
...
          

In the example above, we define one coplet type, the URICoplet, that uses the uri coplet adapter. By this we define a type, that uses URIs to get the content of a coplet.

You can add different coplet types with additional configuration here, but rarely have to touch this file.

Available Coplets

Based on the coplet types, you can define the available coplets in your portal application (= classes). In the example portal an own configuration file contains these so called coplet datas. Here is an excerpt:

...
<coplets>
   <coplet-data id="CZ Weblog" name="standard">
      <title>CZ's Weblog</title>
      <coplet-base-data>URICoplet</coplet-base-data>
      <attribute>
      	<name>uri</name>
      	<value xsi:type="java:java.lang.String" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
          cocoon:/news/liverss?feed=http://radio.weblogs.com/0107211/rss.xml
        </value>
      </attribute>
      <attribute>
      	<name>buffer</name>
      	<value xsi:type="java:java.lang.Boolean" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">true</value>
      </attribute>
      <attribute>
      	<name>error-uri</name>
      	<value xsi:type="java:java.lang.String" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">cocoon:/news/CZ_weblog.rss</value>
      </attribute>
   </coplet-data>
</coplets>
...
          

Each coplet data contains a unique id and additional configuration. A required configuration is the underlying coplet base data. In the example above, the URICoplet is used here.

The above configured coplet data requires some configuration, like the URI to invoke to fetch the content for this coplet. This configuration is passed in the different attributes you see above. Each attribute has a name and value.

The set of coplet datas defines the set of available coplets a user can choose from. If a user chooses to view a coplet, an instance of this coplet data is created. If, e.g. the user chooses the same coplet twice, two instances are created. This is useful for configurable coplets where the user can choose the same coplet with different configurations.

Selected Coplets

The selected coplets are described by the set of coplet instance datas.

...
<coplets>
   <coplet-instance-data id="CZ Weblog-1" name="standard">
      <coplet-data>CZ Weblog</coplet-data>
   </coplet-instance-data>
</coplets>
...
          

The coplet instance data refers to its coplet data by specifying the unique ID. The instance itself has a unique ID as well that is referenced from the portal view.

In addition, a coplet instance data could have own configuration information.

Configuring the arrangement of the defined Coplets

The portal view defines the ordering and arrangement of the coplets. This view is defined in a hierarchical manner by nesting layout objects. At each place, a coplet is located, a reference to a coplet instance data is included.

The Cocoon portal provides several predefined layout elements you can use for your portal view to create a nice layout:

• row - a row of items
• column - a column of items
• tab - a tab

These are the "high-level" objects, you can use to define your structure. You can nest them in any order to create a complex layout. The layout is defined in an XML document as well, so let's have a look at an example:

...
<composite-layout name="row">
  <item>
    <coplet-layout name="coplet">
      <coplet-instance-data>Portal-Intro-1</coplet-instance-data>
    </coplet-layout>
  </item>
  <item>
    <coplet-layout name="coplet">
      <coplet-instance-data>Portal-Bottom-1</coplet-instance-data>
    </coplet-layout>
  </item>
</composite-layout>
...
        

In the example above, we define a row containing two coplets. This is done by selecting the row layout and defining the childs (or items) of this layout. In this case the items are two new layout objects, the coplet layouts that can contain a coplet. The coplet layout has a reference to the coplet instance data.

The Rendering Process

Each layout object has a defined renderer that is used to render this layout object. You can find the renderers in the cocoon.xconf. Each renderer has a unique name that is used to identify this renderer.

A central component, the layout factory (configured in the cocoon.xconf as well), contains a list of all available layout objects, like the row, the column etc. The configuration for each layout object contains also the corresponding renderer information. So, here is the configuration which renderer will be used to render the layout object.

A renderer itself can be configured in various ways. The portal engine uses so called aspects (don't confuse them with AOP), that are used to enhance to features of renderer, allowing - simplifying - a multiple inheritance which is not possible in Java. Have a look at the cocoon.xconf for the different renderer configurations.