| <?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> |