non-releases/trunk_before_flattening/src/documentation/src/content/xdocs/c21-block-portal-profiles/content_en.html - cocoon - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
 <html>
 <head>
 <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
 <title>Configuring Profiles</title>
 <link href="http://purl.org/DC/elements/1.0/" rel="schema.DC">
 <meta content="Overview" name="DC.Subject">
 <meta content="Carsten Ziegeler" name="DC.Creator">
 </head>
 <body>

 <h1>Overview</h1>

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


 <h1>Authentication</h1>

 <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 <a href="../webapps/authentication.html">authentication framework</a> 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>


 <h1>Profile Loading</h1>

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

 <h2>Coplet Types</h2>
 <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>

 <h2>Available Coplets</h2>
 <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>

 <h2>The Portal View</h2>
 <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>


 </body>
 </html>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
	<html>
	<head>
	<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
	<title>Configuring Profiles</title>
	<link href="http://purl.org/DC/elements/1.0/" rel="schema.DC">
	<meta content="Overview" name="DC.Subject">
	<meta content="Carsten Ziegeler" name="DC.Creator">
	</head>
	<body>

	<h1>Overview</h1>

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


	<h1>Authentication</h1>

	<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 <a href="../webapps/authentication.html">authentication framework</a> 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>


	<h1>Profile Loading</h1>

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

	<h2>Coplet Types</h2>
	<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>

	<h2>Available Coplets</h2>
	<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>

	<h2>The Portal View</h2>
	<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>


	</body>
	</html>