2:08 p.m.
Author: mstruk
Date: 2010-03-24 15:08:20 -0400 (Wed, 24 Mar 2010)
New Revision: 2359
Modified:
portal/trunk/docs/reference-guide/en/modules/configuration/Authentication_Token_Configuration.xml
portal/trunk/docs/reference-guide/en/modules/configuration/Dashboard_Configuration.xml
portal/trunk/docs/reference-guide/en/modules/configuration/Data_Injector_Configuration.xml
portal/trunk/docs/reference-guide/en/modules/configuration/Database_Configuration.xml
portal/trunk/docs/reference-guide/en/modules/configuration/Default_Portal_Configuration.xml
portal/trunk/docs/reference-guide/en/modules/configuration/JavaScript_Configuration.xml
portal/trunk/docs/reference-guide/en/modules/configuration/Portal_Default_Permission_Configuration.xml
portal/trunk/docs/reference-guide/en/modules/configuration/Predefined_User_Configuration.xml
portal/trunk/docs/reference-guide/en/modules/configuration/Skin_Configuration.xml
Log:
reference-guide edits - second chapter
Modified:
portal/trunk/docs/reference-guide/en/modules/configuration/Authentication_Token_Configuration.xml
===================================================================
---
portal/trunk/docs/reference-guide/en/modules/configuration/Authentication_Token_Configuration.xml 2010-03-24
16:22:20 UTC (rev 2358)
+++
portal/trunk/docs/reference-guide/en/modules/configuration/Authentication_Token_Configuration.xml 2010-03-24
19:08:20 UTC (rev 2359)
@@ -11,18 +11,18 @@
<emphasis>Token Service</emphasis> is used in authentication.
</para>
<para>
- The token system prevents user account information being sent in clear text mode for
inbound requests. This increases authentication security.
+ The token system prevents user account information being sent in clear text mode
within inbound requests. This increases authentication security.
</para>
<para>
- Token service allows administrators to create, delete, retrieve and clean tokens as
required. The service also defines a validity period of any given token.
- The token becomes invalid once this period expires. This period can be
configured through <emphasis>life-time</emphasis> configuration property.
+ Token service allows administrators to create, delete, retrieve and clean tokens as
required.
+ The service also defines a validity period of any given token. The token becomes
invalid once this period expires.
</para>
</section>
<section
id="sect-Reference_Guide-Authentication_Token_Configuration-Implement_token_services_API">
<title>Implementing the Token Service API</title>
<para>
- All token services used in &PRODUCT;'s authentication must be implemented
by subclassing an <emphasis
role="bold">AbstractTokenService</emphasis> abstract class.
+ All token services used in &PRODUCT; authentication must be implemented by
subclassing an <emphasis role="bold">AbstractTokenService</emphasis>
abstract class.
The following <emphasis
role="bold">AbstractTokenService</emphasis> methods represent the
contract between authentication runtime, and a token service implementation.
</para>
@@ -47,7 +47,7 @@
In the example below, <emphasis>CookieTokenService</emphasis> is a
subclass of <emphasis role="bold">AbstractTokenService</emphasis> so
it has a property which specifies the validity period of the token.
</para>
<para>
- The token service will initialize this validity property by looking for an
<parameter>init-param</parameter> named "<emphasis
role="bold">service.configuration</emphasis>".
+ The token service will initialize this validity property by looking for an
<parameter>init-param</parameter> named <emphasis
role="bold">service.configuration</emphasis>.
</para>
<para>
This property must have three values.
@@ -63,7 +63,7 @@
<type>org.exoplatform.web.security.security.CookieTokenService</type>
<init-params>
<values-param>
- <name>tokenTimeout</name>
+ <name>service.configuration</name>
<value>jcr-token</value>
<value>7</value>
<value>DAY</value>
@@ -91,10 +91,10 @@
</programlistingco>
<para>
- In this case, the service's name is "<emphasis
role="bold">jcr-token</emphasis>" and the token's
expiration time is one week.
+ In this case, the service name is <emphasis
role="bold">jcr-token</emphasis> and the token expiration time is one
week.
</para>
<para>
- &PRODUCT; supports <emphasis>four</emphasis> timing units:
+ &PRODUCT; supports <emphasis>four</emphasis> time units:
</para>
<orderedlist numeration="arabic">
<listitem>
Modified:
portal/trunk/docs/reference-guide/en/modules/configuration/Dashboard_Configuration.xml
===================================================================
---
portal/trunk/docs/reference-guide/en/modules/configuration/Dashboard_Configuration.xml 2010-03-24
16:22:20 UTC (rev 2358)
+++
portal/trunk/docs/reference-guide/en/modules/configuration/Dashboard_Configuration.xml 2010-03-24
19:08:20 UTC (rev 2359)
@@ -6,7 +6,7 @@
<section id="sect-Reference_Guide-Dashboard_configuration">
<title>Dashboard configuration</title>
<para>
- The following parameters are available controll the Dashboard configuration (when in
edit mode):
+ The following parameters are available to control the Dashboard configuration (when in
edit mode):
</para>
<formalpara id="form-Reference_Guide-Dashboard_configuration-owner">
<title>owner</title>
@@ -14,17 +14,17 @@
<orderedlist numeration="arabic">
<listitem>
<para>
- if empty, everyone share the same dashboard and can edit it
+ if empty, everyone shares the same dashboard and can edit it
</para>
</listitem>
<listitem>
<para>
- if set to <emphasis>CURRENTUSER</emphasis> , every user has his own
dashboard
+ if set to <emphasis>CURRENTUSER</emphasis>, every user has his own
dashboard
</para>
</listitem>
<listitem>
<para>
- if set to a username, everyone will see the dashboard of this person
+ if set to a username, everyone shares that user's dashboard
</para>
</listitem>
</orderedlist>
Modified:
portal/trunk/docs/reference-guide/en/modules/configuration/Data_Injector_Configuration.xml
===================================================================
---
portal/trunk/docs/reference-guide/en/modules/configuration/Data_Injector_Configuration.xml 2010-03-24
16:22:20 UTC (rev 2358)
+++
portal/trunk/docs/reference-guide/en/modules/configuration/Data_Injector_Configuration.xml 2010-03-24
19:08:20 UTC (rev 2359)
@@ -8,7 +8,7 @@
<section
id="sect-Reference_Guide-Data_Injector_Configuration-Data_Injector">
<title>Data Injector</title>
<para>
- <emphasis>Data-injector</emphasis> is a utility to initialize enterprise
data for &PRODUCT;. It is packed as a .jar. <!--
+ <emphasis>Data-injector</emphasis> is a utility used to initialize
enterprise data for &PRODUCT;. It is packed as a .jar. <!--
and deployed under $TOMCATHOME/lib. It is started
automatically when Tomcat starts.
-->
@@ -18,7 +18,8 @@
<section
id="sect-Reference_Guide-Data_Injector_Configuration-OrganizationInitializer">
<title>OrganizationInitializer</title>
<para>
- <emphasis>OrganizationInitializer</emphasis> is the service that allows
creating a large organization with many groups and users. It also creates portal
navigation and page(s) for each group and each user.
+ <emphasis>OrganizationInitializer</emphasis> is the service that allows
creating a large organization with many groups and users.
+ It also creates portal navigation and page(s) for each group and each user.
</para>
<formalpara
id="form-Reference_Guide-OrganizationInitializer-Service_configuration_file">
<title>Service configuration file</title>
@@ -162,6 +163,7 @@
<term>FirstName</term>
<listitem>
<para>
+ The user's given name.
</para>
</listitem>
</varlistentry>
@@ -169,7 +171,7 @@
<term>LastName</term>
<listitem>
<para>
- last name.
+ The user's family name.
</para>
</listitem>
</varlistentry>
@@ -185,7 +187,7 @@
<term>Groups</term>
<listitem>
<para>
- A list of the groups that user belongs to.
+ A list of groups that the user belongs to.
</para>
</listitem>
</varlistentry>
@@ -203,10 +205,10 @@
<section
id="sect-Reference_Guide-Data_Injector_Configuration-Automatic_Navigation_Creation">
<title>Automatic Navigation Creation</title>
<para>
- The "
<literal>auto.create.group.page.navigation</literal>" parameter value
is <parameter>true</parameter> or <parameter>false</parameter>. If
this value is set to <parameter>true</parameter> it automatically creates
portal navigations and pages for each group. If <parameter>false</parameter>
it does not.
+ The <literal>auto.create.group.page.navigation</literal> parameter can
have a value of either <parameter>true</parameter> or
<parameter>false</parameter>. If this value is set to
<parameter>true</parameter> it automatically creates portal navigations and
pages for each group. If the value is <parameter>false</parameter> it does
not.
</para>
<para>
- The "<literal>auto.create.user.page.navigation</literal>"
parameter value is the number of pages that are automatically created for each user.
+ The <literal>auto.create.user.page.navigation</literal> parameter value
specifies the number of pages that are automatically created for each user.
</para>
</section>
Modified:
portal/trunk/docs/reference-guide/en/modules/configuration/Database_Configuration.xml
===================================================================
---
portal/trunk/docs/reference-guide/en/modules/configuration/Database_Configuration.xml 2010-03-24
16:22:20 UTC (rev 2358)
+++
portal/trunk/docs/reference-guide/en/modules/configuration/Database_Configuration.xml 2010-03-24
19:08:20 UTC (rev 2359)
@@ -3,8 +3,6 @@
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "../../Reference_Guide.ent">
%BOOK_ENTITIES;
-<!ENTITY % BOOK_ENTITIES SYSTEM "../../Reference_Guide.ent">
-%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-Database_Configuration">
<title>Database Configuration</title>
@@ -13,10 +11,8 @@
<title>Overview</title>
<para>&PRODUCT; has two different database dependencies. One is the
- identity service configuration, which depends on Hibernate. The other
- database dependency is Java content repository (JCR) service, which
- depends on JDBC API, and can integrate with any existing
- datasource implementation.</para>
+ identity service configuration, which depends on Hibernate. The other is Java content
repository (JCR) service, which
+ depends on JDBC API, and can integrate with any existing datasource
implementation.</para>
<para>When you change the database configuration for the first time,
GateIn will automatically generate the proper schema (assuming that the
Modified:
portal/trunk/docs/reference-guide/en/modules/configuration/Default_Portal_Configuration.xml
===================================================================
---
portal/trunk/docs/reference-guide/en/modules/configuration/Default_Portal_Configuration.xml 2010-03-24
16:22:20 UTC (rev 2358)
+++
portal/trunk/docs/reference-guide/en/modules/configuration/Default_Portal_Configuration.xml 2010-03-24
19:08:20 UTC (rev 2359)
@@ -8,11 +8,11 @@
<section
id="sect-Reference_Guide-Default_Portal_Configuration-Overview">
<title>Overview</title>
<para>
- &PRODUCT;'s default home page URL is
<literal>http://${hostname}:${port}/portal/</literal>.
+ &PRODUCT; default home page URL is
<literal>http://{hostname}:{port}/portal/</literal>.
There may be multiple independent portals deployed in parallel at any given
time, each of which has its root
- context (i.e.:
<literal>http://${hostname}:${port}/sample-portal/</literal>).
+ context (i.e.:
<literal>http://{hostname}:{port}/sample-portal/</literal>).
Each portal is internally composed of one or more, what we again call
'portals'. There needs to be at least
- one such portal - the default one is called 'classic'. When accessing
&PRODUCT;'s default home page URL, you
+ one such portal - the default one is called 'classic'. When accessing
&PRODUCT; default home page URL, you
are automatically redirected to 'classic' portal.
The default portal performs another important task. When starting up
&PRODUCT; for the first time, its
Modified:
portal/trunk/docs/reference-guide/en/modules/configuration/JavaScript_Configuration.xml
===================================================================
---
portal/trunk/docs/reference-guide/en/modules/configuration/JavaScript_Configuration.xml 2010-03-24
16:22:20 UTC (rev 2358)
+++
portal/trunk/docs/reference-guide/en/modules/configuration/JavaScript_Configuration.xml 2010-03-24
19:08:20 UTC (rev 2359)
@@ -6,19 +6,23 @@
<section id="sect-Reference_Guide-Javascript_Configuration">
<title>Javascript Configuration</title>
<para>
- Managing Javascript scripts in an application like &PRODUCT; is a critical part of
the configuration work. Configuring the scripts correctly will result in a faster response
time from the portal.
+ Managing Javascript scripts in an application like &PRODUCT; is a critical part of
the configuration work.
+ Configuring the scripts correctly will result in a faster response time from the
portal.
</para>
<para>
- Every portlet can have its own javscript code but in many cases it is more convenient
to reuse some existing shared libraries. For that reason, &PRODUCT; has a mechanism to
easily register the libraries that will be loaded when the first page will be rendered.
+ Every portlet can have its own javscript code but in many cases it is more convenient
to reuse some existing
+ shared libraries. For that reason, &PRODUCT; has a mechanism to easily register
the libraries that will be loaded
+ when the first page will be rendered.
</para>
<para>
- To do so, every WAR deployed in &PRODUCT; can register the
<filename>js</filename> files with the groovy script
"<filename>WEB-INF/conf/script/groovy/JavascriptScript.groovy</filename>".
+ To do so, every WAR deployed in &PRODUCT; can register the
<filename>.js</filename> files with the groovy script
+
<filename>WEB-INF/conf/script/groovy/JavascriptScript.groovy</filename>.
(TODO: this file doesn't seem to exist)
</para>
<para>
The example file below is found in the 01eXoResources.war
</para>
-<programlisting>JavascriptService.addJavascript("eXo",
"/javascript/eXo.js", ServletContext);
+<programlisting
role="JAVA">JavascriptService.addJavascript("eXo",
"/javascript/eXo.js", ServletContext);
/* Animation Javascripts */
JavascriptService.addJavascript("eXo.animation.ImplodeExplode",
"/javascript/eXo/animation/ImplodeExplode.js", ServletContext);
/* Application descriptor */
@@ -65,7 +69,7 @@
Note that even registered dedicated javascripts will be merged into a single
<literal>merged.js</literal> file when the server loads. This reduces the
number of HTTP calls as seen in the home page source code:
</para>
-<programlisting><script type="text/javascript"
src="/portal/javascript/merged.js"></script>
+<programlisting role="XML"><script
type="text/javascript"
src="/portal/javascript/merged.js"></script>
</programlisting>
<para>
Although this optimization is useful for a production environment, it may be easier to
deactivate this optimization while debugging javascript problems.
@@ -80,13 +84,25 @@
The property can be passed as a JVM parameter with the
<literal>-D</literal> option in your <literal>GateIn.sh</literal>
or <literal>GateIn.bat</literal> startup script.
</para>
<para>
- Every javascript file is referenced with a module name of
"<literal>eXo.core.DragDrop</literal>" which acts as a
namespace. Inside the associated files, global javascript functions are used following the
same namespace convention:
+ Every javascript file is associated with a module name which acts as a namespace.
+
+ The module name is passed as a first parameter to JavascriptService.addJavascript()
function as in the following example:
+ </para>
+ <programlisting role="JAVA">
+JavascriptService.addJavascript("eXo.core.DragDrop",
+ "/javascript/eXo/core/DragDrop.js", ServletContext);
+ </programlisting>
+ <para>
+ Inside the associated javascript files, functions are exposed as global javascript
function variables using the module name.
</para>
-
-<programlisting>eXo.core.DragDrop = new DragDrop() ;
-</programlisting>
+ <para> For example:</para>
+ <programlisting role="JAVA">
+eXo.core.DragDrop = new DragDrop();
+ </programlisting>
<para>
- It is also possible to use the eXo.require() javascript method to lazy load and
evaluate some javascript code. This is quite useful from the portlet or widget
applications that will use this javascript only once. Otherwise, if the library is
reusable in several places it is better to reference it in the groovy file.
+ It is also possible to use <literal>eXo.require()</literal> javascript
method to lazy load and evaluate some javascript code.
+ This is quite useful for the portlet or widget applications that will use this
javascript only once. Otherwise,
+ if the library is reusable in several places it is better to reference it in the
groovy file.
</para>
</section>
Modified:
portal/trunk/docs/reference-guide/en/modules/configuration/Portal_Default_Permission_Configuration.xml
===================================================================
---
portal/trunk/docs/reference-guide/en/modules/configuration/Portal_Default_Permission_Configuration.xml 2010-03-24
16:22:20 UTC (rev 2358)
+++
portal/trunk/docs/reference-guide/en/modules/configuration/Portal_Default_Permission_Configuration.xml 2010-03-24
19:08:20 UTC (rev 2359)
@@ -8,7 +8,8 @@
<section
id="sect-Reference_Guide-Portal_Default_Permission_Configuration-Overview">
<title>Overview</title>
<para>
- The permission configuration for the portal is defined in the file
<filename>02portal.war:/WEB-INF/conf/portal/portal-configuration.xml
</filename> . The component UserACL is described there along with other portal
component configurations.
+ The default permission configuration for the portal is defined through
<literal>org.exoplatform.portal.config.UserACL</literal>
+ component configuration in the file
<filename>02portal.war:/WEB-INF/conf/portal/portal-configuration.xml</filename>.
</para>
<para>
It defines 5 permissions types:
@@ -26,7 +27,8 @@
<term>portal.creator.groups</term>
<listitem>
<para>
- This list defines all groups that will be able to manage the different portals.
Members of this group also have the permission to create new portals. The format is
"<literal>membership:/group/subgroup</literal> ".
+ This list defines all groups that will be able to manage the different portals.
Members of this group
+ also have the permission to create new portals. The format is
<literal>membership:/group/subgroup</literal>.
</para>
</listitem>
</varlistentry>
@@ -34,7 +36,7 @@
<term>navigation.creator.membership.type</term>
<listitem>
<para>
- Defines the membership type of the group managers. The group managers have the
permission to create and edit group pages and they can modify the group navigation.
+ Defines the membership type of group managers. The group managers have the
permission to create and edit group pages and they can modify the group navigation.
</para>
</listitem>
</varlistentry>
@@ -42,7 +44,7 @@
<term>guests.group</term>
<listitem>
<para>
- Any anonymous user automatically becomes a member of this group whent they enter
the public pages.
+ Any anonymous user automatically becomes a member of this group when they enter the
public pages.
</para>
</listitem>
</varlistentry>
@@ -50,7 +52,10 @@
<term>access.control.workspace</term>
<listitem>
<para>
- Defines the users that have access to the control workspace. In the demo version
the control workspace is accessible only to 'root' and
'john'. They can expand/collapse the workspace at the left hand side. The
format is "membership:/group/subgroup", An asterisk ''
gives permission to all memberships.
+ Defines the users that have access to the control workspace. In the demo version
the control workspace
+ is accessible only to <emphasis>root</emphasis> and
<emphasis>john</emphasis>. They can expand/collapse
+ the workspace at the left hand side. The format is
<literal>membership:/group/subgroup</literal> -
+ an asterisk '*' gives permission to all memberships.
</para>
</listitem>
</varlistentry>
@@ -94,7 +99,11 @@
<section
id="sect-Reference_Guide-Portal_Default_Permission_Configuration-Overwrite_Portal_Default_Permissions">
<title>Overwrite Portal Default Permissions</title>
-
+
+ <para>When creating custom portals and portal extensions it's possible to
override the default configuration by
+ using <literal>org.exoplatform.portal.config.PortalACLPlugin</literal>,
configuring it as an external-plugin of
+ <literal>org.exoplatform.portal.config.UserACL</literal>
service:</para>
+
<programlisting role="XML"><external-component-plugins>
<target-component>org.exoplatform.portal.config.UserACL</target-component>
<component-plugin>
Modified:
portal/trunk/docs/reference-guide/en/modules/configuration/Predefined_User_Configuration.xml
===================================================================
---
portal/trunk/docs/reference-guide/en/modules/configuration/Predefined_User_Configuration.xml 2010-03-24
16:22:20 UTC (rev 2358)
+++
portal/trunk/docs/reference-guide/en/modules/configuration/Predefined_User_Configuration.xml 2010-03-24
19:08:20 UTC (rev 2359)
@@ -15,21 +15,28 @@
<section
id="sect-Reference_Guide-Predefined_User_Configuration-Plugin_for_adding_users_groups_and_membership_types">
<title>Plugin for adding users, groups and membership types</title>
<para>
- The plugin of type
<literal>org.exoplatform.services.organization.OrganizationDatabaseInitializer</literal>
specifies the list of users, groups and membership types to be created.
+ The plugin of type
<literal>org.exoplatform.services.organization.OrganizationDatabaseInitializer</literal>
is used to specify a list of membership types, a list of groups, and a list of users to be
created.
</para>
<para>
- The initialization parameter
"<parameter>checkDatabaseAlgorithm</parameter>" determines how
the creation is triggered.
+ The <emphasis role="bold">checkDatabaseAlgorithm</emphasis>
initialization parameter determines how the database update is performed.
</para>
<para>
- The value "<literal>entry</literal>" means that each user,
group and membership listed in the configuration file is checked each time &PRODUCT;
is started. If the entry doesn't exist, it is created. The value
"<literal>empty</literal>" sets the configuration file to be
processed only if the database is empty.
+ If its value is set to <emphasis role="bold">entry</emphasis> it
means that each user, group and membership listed in the configuration is checked each
time &PRODUCT; is started.
+ If the entry doesn't yet exist in the database, it is created. If
<emphasis role="bold">checkDatabaseAlgorithm</emphasis> parameter
value is set to <emphasis role="bold">empty</emphasis>,
+ the configuration data will be updated to the database only if the database is
empty.
</para>
</section>
<section
id="sect-Reference_Guide-Predefined_User_Configuration-Membership_types">
<title>Membership types</title>
<para>
- The predefined membership types are specified in the
"<parameter>membershipType</parameter>" field of the
"<parameter>OrganizationConfig</parameter>" plugin parameter.
+ The predefined membership types are specified in the <emphasis
role="bold">membershipType</emphasis> field of the <emphasis
role="bold">OrganizationConfig</emphasis> plugin parameter.
</para>
+ <note>
+ <para>
+ See
<literal>02portal.war:/WEB-INF/conf/organization/organization-configuration.xml</literal>
for the full content.
+ </para>
+ </note>
<programlisting role="XML"><field
name="membershipType">
<collection type="java.util.ArrayList">
@@ -71,7 +78,7 @@
<section
id="sect-Reference_Guide-Predefined_User_Configuration-Groups">
<title>Groups</title>
<para>
- The predefined groups are specified in the "group" field of the
"<parameter>OrganizationConfig</parameter>" plugin parameter.
+ The predefined groups are specified in the <emphasis
role="bold">group</emphasis> field of the <emphasis
role="bold">OrganizationConfig</emphasis> plugin parameter.
</para>
<programlisting role="XML"><field
name="group">
@@ -117,7 +124,7 @@
<section id="sect-Reference_Guide-Predefined_User_Configuration-Users">
<title>Users</title>
<para>
- The predefined users are specified in the
"<parameter>membershipType</parameter>" field of the
"<parameter>OrganizationConfig</parameter>" plugin parameter.
+ The predefined users are specified in the <emphasis
role="bold">membershipType</emphasis> field of the <emphasis
role="bold">OrganizationConfig</emphasis> plugin parameter.
</para>
<programlisting role="XML"><field
name="user">
@@ -151,8 +158,14 @@
<section
id="sect-Reference_Guide-Predefined_User_Configuration-Plugin_for_monitoring_user_creation">
<title>Plugin for monitoring user creation</title>
<para>
- The plugin of type
<literal>org.exoplatform.services.organization.impl.NewUserEventListener
</literal> specifies which groups should join all newly created users. It notably
specifies the groups and memberships to be used. It also specifies a list of users that
should be excepted.
+ The plugin of type
<literal>org.exoplatform.services.organization.impl.NewUserEventListener
</literal> specifies
+ which groups all the newly created users should become members of. It specifies
the groups and the memberships to use
+ (while group is just a set of users, a membership type represents a user's
role within a group).
+ It also specifies a list of users that should not be processed (i.e.
administrative users like 'root').
</para>
+ <note>
+ <para>The terms 'membership' and 'membership type' refer
to the same thing, and are used interchangeably.</para>
+ </note>
<programlisting role="XML"><component-plugin>
<name>new.user.event.listener</name>
Modified:
portal/trunk/docs/reference-guide/en/modules/configuration/Skin_Configuration.xml
===================================================================
---
portal/trunk/docs/reference-guide/en/modules/configuration/Skin_Configuration.xml 2010-03-24
16:22:20 UTC (rev 2358)
+++
portal/trunk/docs/reference-guide/en/modules/configuration/Skin_Configuration.xml 2010-03-24
19:08:20 UTC (rev 2359)
@@ -3,8 +3,6 @@
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "../../Reference_Guide.ent">
%BOOK_ENTITIES;
-<!ENTITY % BOOK_ENTITIES SYSTEM "../../Reference_Guide.ent">
-%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-Skin_Configuration">
<title>Skin Configuration</title>
@@ -50,10 +48,10 @@
</varlistentry>
<varlistentry>
- <term>Portlets skins</term>
+ <term>Portlet skins</term>
<listitem>
- <para>CSS styles for each portlet. Used when a portlet want to
+ <para>CSS styles for each portlet. Used when a portlet wants to
define it's own CSS.</para>
</listitem>
</varlistentry>
@@ -62,8 +60,8 @@
<term>Window styles</term>
<listitem>
- <para>CSS styles for the surrounding of windows (Which embed either
- gadgets or portlets).</para>
+ <para>CSS styles for portlet windows (which surround either
+ gadgets or portlets, and add control buttons and decorations).</para>
</listitem>
</varlistentry>
@@ -71,7 +69,7 @@
<term>Shared styles</term>
<listitem>
- <para>&PRODUCT; WebUI components styles are reused among most of the
+ <para>&PRODUCT; WebUI component styles are reused among most of the
shipped-in portlets.</para>
</listitem>
</varlistentry>
@@ -94,7 +92,7 @@
generates a portal page markup, it inserts stylesheet links in the page's
<literal>head</literal> tag.</para>
- <para>In the snipped code below you can see two types of links:</para>
+ <para>In the snippet code below you can see two types of links:</para>
<programlistingco>
<areaspec>
@@ -118,7 +116,7 @@
(<literal>id="CoreSkin"</literal>).</para>
</callout>
<callout
arearefs="area-Reference_Guide-Skin_Configuration-Stylesheets">
- <para>Portlets skins stylesheets (all
+ <para>Portlet skins stylesheets (all
others). Each portlet within the page may contribute its
own style(s)</para>
</callout>
@@ -133,9 +131,9 @@
<section
id="sect-Reference_Guide-Tips_and_Tricks-Set_the_default_skin">
<title>Set the default skin</title>
- <para>The default skin of portal is called Default. To change this value
- add a skin tag in the <literal>portal.xml</literal> that defines your
- portal:</para>
+ <para>The default skin of the portal is called Default. To change this value
+ add a <literal>skin</literal> tag in
<literal>portal.xml</literal> configuration file,
+ where your portal is defined:</para>
<programlisting role="XML"><portal-config>
<portal-name>classic</portal-name>
@@ -155,19 +153,19 @@
<section
id="sect-Reference_Guide-How_to_Configure_a_Portal_Skin-SkinService">
<title>SkinService</title>
- <para>The SkinService is an &PRODUCT; service that manages portal skin,
- portlet styles and portlet themes (windows borders).</para>
+ <para>The SkinService is a &PRODUCT; service that manages the portal
skin,
+ portlet styles and portlet themes (window borders).</para>
</section>
<section
id="sect-Reference_Guide-How_to_Configure_a_Portal_Skin-SkinConfigListener">
<title>ResourceRequestFilter</title>
- <para>&PRODUCT; automatically discovers web archives that contains a
- file descriptor for skins (WEB-INF/gatein-resources.xml).</para>
+ <para>&PRODUCT; automatically discovers web archives that contain a
+ file descriptor for skins
(<filename>WEB-INF/gatein-resources.xml</filename>).</para>
<para>Because of the Right-To-Left support all CSS files need to be
- retrieved through a Servlet filter and the web application need to be
- configured to activate this filter. This is already done for the
+ retrieved through a Servlet filter and the web application needs to be
+ configured to activate this filter. This is already done for
01eXoResources.war web application.</para>
<programlisting role="XML"><filter>
@@ -184,25 +182,30 @@
<section>
<title>Skin configuration</title>
- <para>&PRODUCT; automatically discovers web archives that contains a
- file descriptor for skins (WEB-INF/gatein-resources.xml).The
+ <para>&PRODUCT; automatically discovers web archives that contain a
+ file descriptor for skins
(<filename>WEB-INF/gatein-resources.xml</filename>).The
full schema can be found in
- 02portal.war:/WEB-INF/gatein_resources_1-0.xsd</para>
+
<filename>02portal.war:/WEB-INF/gatein_resources_1-0.xsd</filename></para>
- <para>Here is an
example:<programlisting><gatein-resources>
+ <para>Here is an example:
+ </para>
+ <programlisting role="XML"><gatein-resources>
<portal-skin>
<skin-name>MySkin</skin-name>
<css-path>/skin/myskin.css</css-path>
<overwrite>false</overwrite>
</portal-skin>
-</gatein-resources></programlisting></para>
+</gatein-resources>
+ </programlisting>
<para>Here we defined a skin (MySkin) and the CSS location within the
same web archive.</para>
<para>Default portal skin and window styles are defined in
- 01eXoResources.war:/WEB-INF/gatein-resources.xml and the part dedicated to
- skinning is defined like:<programlisting><gatein-resources
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.gatein.org/xml/ns/gatein_resources_1_...
xmlns="http://www.ga
+ <filename>01eXoResources.war:/WEB-INF/gatein-resources.xml</filename> and
the part dedicated to
+ skinning is defined like:
+ </para>
+ <programlisting role="XML"><gatein-resources
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.gatein.org/xml/ns/gatein_resources_1_...
xmlns="http://www.ga
tein.org/xml/ns/gatein_resources_1_0.xsd">
<portal-skin>
<skin-name>Default</skin-name>
@@ -227,26 +230,28 @@
<style-theme>
<theme-name>SimpleGreen</theme-name>
</style-theme>
- </window-style></programlisting></para>
+ </window-style></programlisting>
</section>
<section>
<title>Skin icon</title>
- <para>When selecting a skin, an overview of the skin is possible. It has
+ <para>When selecting a skin, a preview of the skin is possible. It has
to be defined in the current skin used to display the form to change
skins.</para>
- <para>Put the screeshot of the skin in:
-
<literal>01eXoResources.war:/skin/DefaultSkin/portal/webui/component/customization/UIChangeSkinForm/background</literal>
+ <para>Put the screenshot of the skin in:
+
<filename>01eXoResources.war:/skin/DefaultSkin/portal/webui/component/customization/UIChangeSkinForm/background</filename>
and add the following in
-
01eXoResources.war:/skin/DefaultSkin/portal/webui/component/customization/UIChangeSkinForm/Stylesheet.css:<programlisting>.UIChangeSkinForm
.UIItemSelector .TemplateContainer .<emphasis
+
<filename>01eXoResources.war:/skin/DefaultSkin/portal/webui/component/customization/UIChangeSkinForm/Stylesheet.css:</filename>
+ </para>
+ <programlisting>.UIChangeSkinForm .UIItemSelector .TemplateContainer
.<emphasis
role="bold">MySkin</emphasis>Image {
margin: auto;
width: 329px; height:204px;
background: url('background/<emphasis
role="bold">MySkin</emphasis>.jpg') no-repeat top;
cursor: pointer ;
-}</programlisting></para>
+}</programlisting>
</section>
</section>
@@ -264,13 +269,13 @@
</imageobject>
</mediaobject></para>
- <para>The code below illustrates the inclusion of all CSS resoucres for a
+ <para>The code below illustrates the inclusion of all CSS resources for a
new theme from the example file
<literal>GateInResourcesCp060508/skin/MyPortalSkin/PortletThemes/Stylesheet.css</literal>.</para>
<orderedlist>
<listitem>
- <para>In 01eXoResources:/WEB-INF/gatein-resources.xml add the
+ <para>In
<filename>01eXoResources:/WEB-INF/gatein-resources.xml</filename> add the
following snippet:<programlisting><window-style>
<style-name>MyTheme</style-name>
<style-theme>
@@ -423,7 +428,7 @@
<section
id="sect-Reference_Guide-Skin_Configuration-Portlet_Styles">
<title>How to create new Portlet skins</title>
- <para>Portlets often require additionnal styles that may not be defined by
+ <para>Portlets often require additional styles that may not be defined by
the portal skin. &PRODUCT; allows portlets to define additional
stylesheets for each portlet and will append the corresponding
<literal>link</literal> tags to the
<literal>head</literal>.</para>
@@ -435,7 +440,7 @@
<parameter>id="content<literal>ContentPortlet"</literal></parameter></para>
<para>To define a new CSS file to include whenever a portlet is added, the
- following snippet need to be added in
gatein-resources.xml<programlisting><portlet-skin>
+ following snippet needs to be added in
gatein-resources.xml<programlisting><portlet-skin>
<application-name>portletAppName</application-name>
<portlet-name>PortletName</portlet-name>
<skin-name>Default</skin-name>
@@ -450,7 +455,7 @@
</portlet-skin></programlisting></para>
<para>The portal framework will include the CSS file corresponding to the
- skin in used.</para>
+ skin used.</para>
<section
id="sect-Reference_Guide-Tips_and_Tricks-Change_portlet_icons">
@@ -462,13 +467,13 @@
<itemizedlist>
<listitem>
-
<para><filename>skin/DefaultSkin/portletIcons<replaceable>icon_name.png</replaceable></filename>.
+
<para><filename>skin/DefaultSkin/portletIcons/<replaceable>icon_name.png</replaceable></filename>.
To be used correctly the icon must be named after the
portlet.</para>
</listitem>
</itemizedlist>
- <para>For example,the icon for an account portlet named AccountPortlet
+ <para>For example, the icon for an account portlet named AccountPortlet
would be located at:</para>
<itemizedlist>
@@ -503,12 +508,13 @@
<literal>exo.product.developing</literal> to
<literal>true</literal>.</para>
- <para>For example, the property can passed as a JVM parameter with the
- <literal>-D</literal> option when running
GateIn.<programlisting>sh $JBOSS_HOME/bin/run.sh
-Dexo.product.developing=true</programlisting></para>
+ <para>For example, the property can be passed as a JVM parameter with
+ <literal>-D</literal> option when running GateIn.</para>
+ <programlisting>sh $JBOSS_HOME/bin/run.sh
-Dexo.product.developing=true</programlisting>
<orderedlist numeration="arabic">
<listitem>
- <para>warning("This is option may cause display bugs with certain
+ <para>warning("This option may cause display bugs with certain
browsers like Internet Explorer")</para>
</listitem>
</orderedlist>
@@ -520,7 +526,7 @@
studying &PRODUCT; CSS.</para>
<para>&PRODUCT; relies heavily on CSS to create the layout and effects
- for the UI. Some common techniques for customizing &PRODUCT;'s CSS are
+ for the UI. Some common techniques for customizing &PRODUCT; CSS are
explained below.</para>
<section
id="sect-Reference_Guide-Some_CSS_techniques-Decorator_pattern">
5184
days inactive
5184
days old
gatein-commits@lists.jboss.org
0 comments
1 participants
participants (1)
-
do-not-reply＠jboss.org