You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by cz...@apache.org on 2004/03/04 17:38:22 UTC
cvs commit: cocoon-2.1/src/documentation/xdocs/developing/portal profiles.xml book.xml coplets.xml
cziegeler 2004/03/04 08:38:22
Modified: src/documentation/xdocs/developing/portal book.xml
coplets.xml
Added: src/documentation/xdocs/developing/portal profiles.xml
Log:
Updating docs
Revision Changes Path
1.6 +2 -0 cocoon-2.1/src/documentation/xdocs/developing/portal/book.xml
Index: book.xml
===================================================================
RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/developing/portal/book.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- book.xml 23 Feb 2004 14:52:49 -0000 1.5
+++ book.xml 4 Mar 2004 16:38:22 -0000 1.6
@@ -13,7 +13,9 @@
<menu label="Portal">
<menu-item label="Introduction" href="index.html"/>
<menu-item label="Portal Engine" href="portal-block.html"/>
+ <menu-item label="Coplets" href="coplets.html"/>
<menu-item label="Event Handling" href="events.html"/>
+ <menu-item label="Profiles" href="profiles.html"/>
<menu-item label="Authentication" href="../webapps/authentication.html"/>
</menu>
<menu label="Samples">
1.2 +48 -6 cocoon-2.1/src/documentation/xdocs/developing/portal/coplets.xml
Index: coplets.xml
===================================================================
RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/developing/portal/coplets.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- coplets.xml 4 Mar 2004 08:08:55 -0000 1.1
+++ coplets.xml 4 Mar 2004 16:38:22 -0000 1.2
@@ -212,6 +212,7 @@
gettable. If you set a timeout, the content is automatically
buffered and the <em>buffer</em> configuration is ignored.
</p>
+ </s2>
</s1>
<s1 title="The URICoplet">
<p>
@@ -263,13 +264,54 @@
</s2>
</s1>
<s1 title="Coplet Rendering">
- <!-- ACHTUNG DAS HIER SIND ASPECTE, nicht attribute!!!!!! -->
<p>
Each coplet can be configured for supporting different features, like minimizing
- or removing.
+ or removing. These are aspect configurations that are configured similar to
+ attributes.
</p>
<s2 title="Sizing">
- </s2>
+ <p>
+ By default, the window size of a coplet can be changed by the user.
+ The user can choose between maximized and minimized.
+ </p>
+ <p>
+ This is configurable by the boolean aspect <em>sizable</em> on
+ the coplet data (class). The default is true:
+ </p>
+ <source>
+<![CDATA[...
+ <coplet-data id="CZ Weblog" name="standard">
+ <title>CZ's Weblog</title>
+ <coplet-base-data>URICoplet</coplet-base-data>
+ <aspect>
+ <name>sizable</name>
+ <value xsi:type="java:java.lang.Boolean" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ false
+ </value>
+ </aspect>
+ </coplet-data>
+...]]>
+ </source>
+ <p>
+ In addition the size of a coplet (minimized/maximized) can be preconfigured
+ as well by the integer aspect value <em>size</em>. The value <em>0</em>
+ means minimized and <em>1</em> is maximized (with 1 as the default).
+ </p>
+ <source>
+<![CDATA[...
+ <coplet-data id="CZ Weblog" name="standard">
+ <title>CZ's Weblog</title>
+ <coplet-base-data>URICoplet</coplet-base-data>
+ <aspect>
+ <name>size</name>
+ <value xsi:type="java:java.lang.Integer" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ 0
+ </value>
+ </aspect>
+ </coplet-data>
+...]]>
+ </source>
+ </s2>
<s2 title="Mandatory Coplets">
<p>
By default, the user can delete any coplet from his portal view. However
@@ -278,7 +320,7 @@
by the user.
</p>
<p>
- This is configurable by the boolean attribute <em>mandatory</em> on
+ This is configurable by the boolean aspect <em>mandatory</em> on
the coplet data (class). The default is false:
</p>
<source>
@@ -286,12 +328,12 @@
<coplet-data id="CZ Weblog" name="standard">
<title>CZ's Weblog</title>
<coplet-base-data>URICoplet</coplet-base-data>
- <attribute>
+ <aspect>
<name>mandatory</name>
<value xsi:type="java:java.lang.Boolean" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
true
</value>
- </attribute>
+ </aspect>
</coplet-data>
...]]>
</source>
1.1 cocoon-2.1/src/documentation/xdocs/developing/portal/profiles.xml
Index: profiles.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "../../dtd/document-v10.dtd">
<document>
<header>
<title>Configuring Profiles</title>
<subtitle>Overview</subtitle>
<authors>
<person name="Carsten Ziegeler" email="cziegeler@apache.org"/>
</authors>
</header>
<body>
<s1 title="Overview">
<p>
This document gives an overview over configuring profiles.
</p>
<p>
The portal engine uses a component for managing the profile of the
current user. There are different implementations already available.
The static profile manager gives ever user the same profile whereas
the default profile manager chooses the profile of the user based
on the role and the user. In this chapter we describe this mechanism
and how it can be configured.
</p>
</s1>
<s1 title="Authentication">
<p>
The portal engine uses the authentication framework to authenticate
a user. This is the default configuration that is also used in the
provided sample. However, the portal is not tied to that framework
so whenever the need arises you can implement your own authentication
mechanism and use it in the portal.
</p>
<p>
When the authentication framework is used for authenticating the user,
the profile is selected (or can be selected) on the role the user is in.
Therefore the authentication framework has to deliver the role name
of the user in the authentication XML (for more information about the
authentication, read the <link href="../webapps/authentication.html">authentication framework</link> documentation.)
</p>
<p>
The current sample of the portal returns already a role for the registered
users (the two roles guest and admin are used).
</p>
</s1>
<s1 title="Profile Loading">
<p>
When a user logs into the portal, the profile for this user is loaded
and then stored in the session. As explained in the chapters about
coplets, the profile of a user consists of several parts: the coplet base
data (coplet types), the coplet data (classes), the coplet instance datas
(instances) and the layout (ordering of the coplets).
</p>
<p>
In the following we describe the default setting of the portal. All
profiles are stored as XML files in a distinct directory. However, if
you want to store your profiles in a different location, you can
configure this location or you can also store the profiles in a
database or any other persistence layer.
</p>
<s2 title="Coplet Types">
<p>
Each part is described in a different XML configuration file. The coplet
base data (coplet types) is a global setting that is not user/role
dependent. All other parts can differ based on the current user and his
role.
</p>
<p>
The default location for this profile is <em>profiles/copletbasedata/portal.xml</em>.
</p>
</s2>
<s2 title="Available Coplets">
<p>
The coplet data (=classes) defines the set of available coplets for the
current user. The user can choose any of these coplets in his view.
If a user has selected a coplet, an instance of this coplet is created.
</p>
<p>
The list of available/allowed coplets is defined in three steps.
</p>
<ol>
<li>First the global list with coplets for all users is read.</li>
<li>Then a list with coplets for the current role is read and added
to the global list. This list is optional.</li>
<li>Finally, a list with coplets for the current user is added
to the list. This list is also optional.</li>
</ol>
<p>
By default all profiles for the coplet data are stored in the directory
<em>profiles/copletdata</em>. The global profile has the filename
<em>portal.xml</em>. The file name for the different role profiles
is <em>portal-role-NAME_OF_ROLE.xml</em>. And the name of the
profile for the user is <em>portal-user-USER_NAME.xml</em>.
</p>
<p>
In most cases it's sufficient to add the coplets that are available
to all users in the global list. In addition you will define some
role based profiles for the different roles where you add coplets
that are only available for this role, like some administration
coplets that are only meant for administrators.
</p>
<p>
It is currently not possible to disable a coplet in a role or user
profile that has been enabled in the global (or role profile). The
reverse isn't possible as well (disabling in global, enabling in
role)!
</p>
</s2>
<s2 title="The Portal View">
<p>
The portal view for a user consists of two parts: the select coplets
(= the coplet instances) and the layout. The layout defines the ordering
and the arrangement of the coplets.
</p>
<p>
Usually each user has his own portal view. The layout for the user
is defined in <em>profiles/layout/portal-user-USER_NAME.xml</em>
and the instances are defined in <em>profiles/copletinstancedata/portal-user-USER_NAME.xml</em>.
</p>
<p>
However, in some cases each user of a distinct role has the same
portal view, so you can define role based portal views.
The two configuration files are in the <em>profiles/layout</em>
and in the <em>profiles/copletinstancedata</em> directory
and have the name <em>portal-role-NAME_OF_ROLE.xml</em>.
</p>
<p>
This role based portal view is also used when a user logs into the
portal for the first time and hasn't "created" his own portal view yet.
</p>
<p>
In addition you can define a global setting for the portal view
with the two configuration files in the two above mentioned directories.
Give them both the name <em>portal.xml</em>. This portal view is used
whenever the user doesn't have an own portal view and no role based
view exists.
</p>
</s2>
</s1>
</body>
</document>