Author: emuckenhuber
Date: 2007-11-28 10:41:20 -0500 (Wed, 28 Nov 2007)
New Revision: 9168
Added:
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/widgetintegration.xml
Modified:
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/master.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/ajax.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/authentication.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/clustering.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/cmsPortlet.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/configuration.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/contentintegration.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/errorhandling.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/identity.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/identityportlets.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/installation.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/ldap.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/migration.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portalapi.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portletmodes.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/security.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/sso.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/themeandlayouts.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/tutorials.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/xmldescriptors.xml
Log:
- some typos
Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/master.xml
===================================================================
--- docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/master.xml 2007-11-28 14:18:08
UTC (rev 9167)
+++ docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/master.xml 2007-11-28 15:41:20
UTC (rev 9168)
@@ -27,6 +27,7 @@
<!ENTITY security SYSTEM "modules/security.xml">
<!ENTITY troubleshooting SYSTEM "modules/troubleshooting.xml">
<!ENTITY contentintegration SYSTEM
"modules/contentintegration.xml">
+ <!ENTITY widgetintegration SYSTEM "modules/widgetintegration.xml">
<!ENTITY portalapi SYSTEM "modules/portalapi.xml">
<!ENTITY errorhandling SYSTEM "modules/errorhandling.xml">
<!ENTITY portletmodes SYSTEM "modules/portletmodes.xml">
@@ -80,6 +81,7 @@
<!-- Understanding urls --> &urls;
<!-- Error handling --> &errorhandling;
<!-- Content integration --> &contentintegration;
+ <!-- Widget integration --> &widgetintegration;
<!-- Portlet modes --> &portletmodes;
<!-- Portal API --> &portalapi;
<!-- Clustering configuration --> &clustering;
Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/ajax.xml
===================================================================
--- docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/ajax.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++ docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/ajax.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -161,7 +161,7 @@
The name of the property is
<emphasis>theme.dyna.partial_refresh_enabled</emphasis> and its values can
be <emphasis>true</emphasis> or
<emphasis>false</emphasis>. When this property is set on an object
it is automatically inherited by the sub hierarchy located under that
object. By default the drag
- and drop feature is positionned on the dashboard object and not on the
rest of the portal objects.
+ and drop feature is positioned on the dashboard object and not on the rest
of the portal objects.
</para>
<programlisting><![CDATA[
<deployment>
@@ -185,7 +185,7 @@
The partial page refresh feature is compatible with the Portal API. The
Portal API allows programmatic
update of the state of portlets at runtime. For instance it is possible to
modify the window state or
the mode of several portlets on a given page. When such event occurs, the
portal detects the changes
- which occured and will update the portlet fragments in the page.
+ which occurred and will update the portlet fragments in the page.
</note>
<para>It is possible to change that behavior at runtime using the
property editor of the management portlet.
If you want to enable partial refreshing on the default portal you should set
the property to true
@@ -247,13 +247,13 @@
<para>When partial refresh is activated, the state of a page can
potentially become inconsistent. for
example, if some objects are shared in the application scope of the
session between portlets. When one
portlet update a session object, the other portlet won't be refreshed
and will still display content based
- on the previous value of the object in the session. To avoid that, partial
refresh can be desactivated
+ on the previous value of the object in the session. To avoid that, partial
refresh can be deactivated
for certain portlets by adding
<portlet-refresh>false<portlet-refresh> in the
jboss-portlet.xml file.</para>
</sect4>
<sect4>
<title>Non ajax interactions</title>
- <para>The solution developped by JBoss Portal on the client side is
built on top of DOM events emitted
- by the web browser when the user interracts with the page. If an
interaction is done without an
+ <para>The solution developed by JBoss Portal on the client side is
built on top of DOM events emitted
+ by the web browser when the user interacts with the page. If an
interaction is done without an
emission of an event then JBoss Portal will not be able to transform it
into a partial refresh and
it will result instead of a full refresh. This can happen with
programmatic submission of forms.
</para>
Modified:
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/authentication.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/authentication.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/authentication.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -23,7 +23,7 @@
<sect2 id="authentication_configuration">
<title>Configuration</title>
<para>You can configure the JAAS authentication stack in
<emphasis>jboss-portal.sar/conf/login-config.xml</emphasis>.
- It is important to remember that authorisation in portal starts at the JAAS
level -
+ It is important to remember that authorization in portal starts at the JAAS
level -
configured <emphasis>LoginModule</emphasis>s apply proper
<emphasis>Principal</emphasis> objects representing
the roles of authenticated user. As you can see in
<emphasis>jboss-portal.sar/portal-server.war/WEB-INF/web.xml</emphasis>
portal
servlet is secured with specified role
("<emphasis>Authenticated</emphasis>"). In the default portal
configuration
@@ -40,7 +40,7 @@
<sect2>
<title>org.jboss.portal.identity.auth.IdentityLoginModule</title>
<para>This is the standard portal LoginModule implementation that uses
portal identity modules in order to search users and roles.
- By default it is the only configured LoginModule in the portal authentication
stack. Its behaviour can be altered with the following options:
+ By default it is the only configured LoginModule in the portal authentication
stack. Its behavior can be altered with the following options:
<itemizedlist>
<listitem>
<emphasis
role="bold">userModuleJNDIName</emphasis> - JNDI name of portal
UserModule.
@@ -134,7 +134,7 @@
It extends it so all configuration that can be applied to
<emphasis>LdapExtLoginModule</emphasis> remains valid here. For a user that
was authenticated successfully it will try to call the identity modules from
portal, then check if such user
exists or not, and if does not exist it will try to create it. Then for all
roles assigned to this authenticated principal it will
- try to check and create them using identity modules. This behaviour can be
altered using following options:
+ try to check and create them using identity modules. This behavior can be
altered using following options:
<itemizedlist>
<listitem>
<emphasis
role="bold">userModuleJNDIName</emphasis> - JNDI name of portal
UserModule. This option is <emphasis>obligatory</emphasis>
@@ -214,7 +214,7 @@
<para>
This module is designed to provide synchronization support for any other
LoginModule placed in the authentication stack.
It leverages the fact that in JAAS authentication process occurs in two
phases. In first phase when login() method is invoked
- it always returns "true". Because of this behaviour
<emphasis>SynchronizingLoginModule</emphasis> should be always used with
+ it always returns "true". Because of this behavior
<emphasis>SynchronizingLoginModule</emphasis> should be always used with
"optional" flag.
More over it should be placed after the module we want to leverage as a
source for synchronization and that module should have "required" flag set.
During the second phase when commit() method is invoked it gets user
<emphasis>Subject</emphasis> and its
<emphasis>Principal</emphasis>s
Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/clustering.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/clustering.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/clustering.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -13,7 +13,7 @@
</author>
</chapterinfo>
<title>Clustering Configuration</title>
- <para>This section covers configuring JBoss Portal to function in a clustered
environment.</para>
+ <para>This section covers configuring JBoss Portal for a clustered
environment.</para>
<sect1>
<title>Introduction</title>
<para>JBoss Portal leverages various clustered services that are found in
JBoss Application Server. This section
@@ -35,7 +35,7 @@
concurrency issues when
deploying the various *-object.xml files. Without that, each node
would try to create the
same objects in the database when it deploys an archive
containing such descriptors.</listitem>
- <listitem>Used with JCR. The jackrabbit server is not able to
run in a cluster
+ <listitem>Used with JCR. The Jackrabbit server is not able to
run in a cluster
by itself, therefore we make a singleton on the cluster. This
provides HA-CMS, which is
similar to the current HA JBossMQ provided in JBoss
AS.</listitem>
</orderedlist>
@@ -63,7 +63,7 @@
<note>JBoss Clustering details can be found in the
<ulink
url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossHA">Wiki&...
or the
- <ulink
url="http://www.jboss.com/products/jbossas/docs">clustering
documentation</ulink>.
+ <ulink
url="http://labs.jboss.com/jbossas/docs/">clustering
documentation</ulink>.
</note>
<imageobject>
<imagedata fileref="images/clustering/overview.png"
format="png"/>
@@ -74,9 +74,9 @@
<title>Considerations</title>
<para>When you want to run JBoss Portal on a cluster there are a few things
to keep in mind:
<itemizedlist>
- <listitem>Deploy the portal under the <emphasis
role="bold">all</emphasis> application server configuration as it
contains the clustering services that JBoss Portal leverages.</listitem>
+ <listitem>Deploy the portal under the <emphasis
role="bold">all</emphasis> application server configuration as it
contains the clustering services that is leveraged by JBoss Portal.</listitem>
<listitem>All the portal instances have to use the same datasource : the
database is used to store the portal
- persistent state like pages. If you don't use a shared database then you
will have consitency problems.</listitem>
+ persistent state like pages. If you don't use a shared database then you
will have consistency problems.</listitem>
</itemizedlist></para>
</sect1>
@@ -85,15 +85,15 @@
<sect2 id="PortalSessionReplication">
<title>Portal Session Replication</title>
- <para>The portal associates with each user an http session in order to
keep specific objects such as:
+ <para>The portal associates with each user a http session in order to keep
specific objects such as:
<itemizedlist>
- <listitem>Navigational state : this is mainly the state of the different
portlet windows that the user will manipulate
+ <listitem>Navigational state : this is mainly the state of different
portlet windows that the user will manipulate
during its interactions with the portal. For instance a maximized portlet window
with specific render parameters.</listitem>
<listitem>WSRP objects : the WSRP protocol can require to provide specific
cookies during interactions with a remote
portlet.</listitem>
</itemizedlist>
- Replicating the portal session ensures that this state will be kept in sync on
the cluster, e.g he will see the portlet
- window he uses exactly the same on every node. The activation of the portal
session replication is made through the
+ Replicating the portal session ensures that this state will be kept in sync on
the cluster, e.g The user will see exactly
+ the same portlet window on every node of the cluster. The activation of the
portal session replication is made through the
configuration of the web application that is the main entry point of the portal.
This setting is available in the file
<emphasis>jboss-portal.sar/portal-server.war/WEB-INF/web.xml</emphasis></para>
<para>
@@ -170,8 +170,8 @@
<sect2>
<title>Identity clustering</title>
<para>JBoss Portal leverages the servlet container authentication for its
own authentication mechanism. When
- the user is authenticated on one particular node he will have to
reauthenticate again if he use another
- node of the cluster (during a failover for instance). This is valid only for
the <emphasis>FORM</emphasis>
+ the user is authenticated on one particular node he will have to
reauthenticate again if a different
+ node of the cluster (during a failover for instance) is used. This is valid
only for the <emphasis>FORM</emphasis>
based authentication which is the default form of authentication that JBoss
Portal uses. Fortunately JBoss
provides transparent reauthentication of the user called JBoss clustered SSO.
Its configuration can be found
in
<literal>$JBOSS_HOME/server/all/deploy/jboss-web.deployer/server.xml</literal>
and you will need to
@@ -241,7 +241,7 @@
</mbean>]]></programlisting>
</para>
<para>Setup a database that will be shared by the two nodes and obviously we
cannot use
- an embedded database. For instance using postgresql we would copy the file
<emphasis>portal-postgresql-ds.xml</emphasis>
+ an embedded database. For instance using postgresql we would need to copy the file
<emphasis>portal-postgresql-ds.xml</emphasis>
into <emphasis>$JBOSS_HOME/server/ports-01/deploy</emphasis> and
<emphasis>$JBOSS_HOME/server/ports-02/deploy</emphasis>.
</para>
<para>Copy JBoss Portal HA to the deploy directory of the two
configurations.</para>
Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/cmsPortlet.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/cmsPortlet.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/cmsPortlet.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -34,7 +34,7 @@
<para>The methodology of serving content within the CMSPortlet, allows for
some beneficial
features, like:</para>
<listitem>Search-engine friendly URLs:
http://domain/[portal]/content/company.html</listitem>
- <listitem>Serve binaries with simple urls independant of the portal:
+ <listitem>Serve binaries with simple urls independent of the portal:
http://domain/content/products.pdf</listitem>
<listitem>Deploy several instances of the CMSPortlet on any page and
configure them to
display different start pages.</listitem>
@@ -76,7 +76,7 @@
The portal is also able to map urls content to the CMS through a specific
window.
- The CMS portlet default page is defined as a preference and can be overriden
like any
+ The CMS portlet default page is defined as a preference and can be overridden
like any
other preference up to the user's preference level. The default CMS
portlet displayed
when you install JBoss Portal for the first time is describe in the following
file:
<emphasis>jboss-portal.sar/portal-core.war/WEB-INF/portlet.xml</emphasis>
@@ -90,7 +90,7 @@
</portlet-preferences>]]></programlisting>
<para>
The preference key is "indexpage". To change the default page, just
make sure to create
- an html document using the CMS Admin portlet then change the value of
"indexpage" to
+ an HTML document using the CMS Admin portlet then change the value of
"indexpage" to
the corresponding path.
</para>
</section>
@@ -338,7 +338,7 @@
<para>
To add or remove an interceptor, you just need to edit the following file:
<literal>portal-cms-sar/META-INF/jboss-service.xml</literal>.
- It works the same way as the server interceptor, for each interceptor you
need to define an mbean then add it
+ It works the same way as the server interceptor, for each interceptor you
need to define an MBean then add it
to the cms interceptor stack. For example, if you have the 2 default
interceptors, you should have the following
lines in the jboss-service.xml file:
<programlisting><![CDATA[<!-- ACL Security Interceptor -->
@@ -429,7 +429,7 @@
</mbean>
]]>
</programlisting>
- The first two mbeans define the interceptors and the third mbean, define
which interceptors to add to
+ The first two MBeans define the interceptors and the third MBean, define
which interceptors to add to
the CMS service.
</para>
<para>
Modified:
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/configuration.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/configuration.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/configuration.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -129,7 +129,7 @@
<sect1 id="configuration-hibdialect">
<title>Forcing the DB dialect</title>
<para>If you encounter that the Hibernate dialect is not working properly and
would like to
- override the default behaviour, follow the instructions contained in this
section:
+ override the default behavior, follow the instructions contained in this
section:
<note>Under most common circumstances, the auto-detect feature should work
fine.</note>
</para>
<sect2>
Modified:
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/contentintegration.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/contentintegration.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/contentintegration.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -10,7 +10,7 @@
<title>Content Integration</title>
<para>Since JBoss Portal 2.6 it is possible to provide an easy integration of
content within the portal. Up to the 2.4 version
content integration had to be done by configuring a portlet to show some content from
an URI and then place that
- portlet on a page. The new content integration capabilities allows to directly
configure a page window with the content URI
+ portlet on a page. The new content integration capabilities allows to directly
configure a page window with the content URI by
removing the need to configure a portlet for that purpose.</para>
<note>We do not advocate to avoid the usage portlet preferences, we rather
advocate that content configuration managed at the portal level
simplifies the configuration: it helps to make content a first class citizen of the
portal instead of having an intermediary
@@ -40,13 +40,13 @@
the portal cannot interpret and is left up to the content provider to
interpret.</listitem>
<listitem>The window content type which defines how the portal
interpret the window content
<itemizedlist>
- <listitem>The default content type is for portlets and has the
value <emphasis>portlet</emphasis>. For that
- content type, the content URI is the portlet instance
id.</listitem>
+ <listitem>The default content type is for portlets and has the
value <emphasis>portlet</emphasis>. In this
+ case the content URI is the portlet instance id.</listitem>
<listitem>The CMS content type allows to integrate content from
the CMS at the page and it has the value
<emphasis>cms</emphasis>. For that content type, the
content URI is the CMS file path.</listitem>
</itemizedlist>
</listitem>
- <listitem>The content parameters which is a set of additional key/value
string pairs holding state that is interpreted
+ <listitem>The content parameters which are a set of additional
key/value string pairs holding state that is interpreted
by the content provider.</listitem>
</itemizedlist>
</para>
@@ -66,7 +66,7 @@
that it is selecting or editing the content portion of the state of a portlet.
<emphasis>select_content</emphasis> is
used to select a new content to put in a window while
<emphasis>edit_content</emphasis> is used to modify the previously
defined content, often the two modes will display the same thing. The traditional
edit mode is not used because the edit mode
- is more targetted to configure how the portlet show content to the end user rather
than what content it shows.</para>
+ is more targeted to configure how the portlet shows content to the end user rather
than what content it shows.</para>
<imageobject>
<imagedata align="center"
fileref="images/content/cms.png" format="png"/>
</imageobject>
@@ -79,10 +79,10 @@
</para>
<sect2>
<title>Displaying content</title>
- <para>At runtime the portal will call the portlet with the view mode when
it displays content. It will send to the
- portlet the information about the content to display using the render
parameters. Therefore the portlet has
+ <para>At runtime the portal will call the portlet with the view mode when
it displays content. It will send
+ information about the content to display using the render parameters to the
portlet. Therefore the portlet has
just to read the render parameters and use them to properly display the content
in the portlet. The render parameters
- values are the key/value pairs that forms the content properties and the
resource URI is found under the <emphasis>uri</emphasis>
+ values are the key/value pairs that form the content properties and the resource
URI is available under the <emphasis>uri</emphasis>
parameter name.</para>
</sect2>
<sect2>
@@ -135,8 +135,8 @@
</sect3>
<sect3>
<title>Overriding the dispatch method</title>
- <para>First the <emphasis>doDispatch(RenderRequest req,
RenderResponse resp)</emphasis> is overriden in order
- to branch the requeset flow to a method that will take care of displaying the
editor.</para>
+ <para>First the <emphasis>doDispatch(RenderRequest req,
RenderResponse resp)</emphasis> is overridden in order
+ to branch the request flow to a method that will take care of displaying the
editor.</para>
<programlisting><![CDATA[
protected void doDispatch(RenderRequest req, RenderResponse resp)
throws PortletException, PortletSecurityException, IOException
Modified:
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/errorhandling.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/errorhandling.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/errorhandling.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -28,7 +28,7 @@
is also called <emphasis>control policy</emphasis>.</para>
<sect2>
<title>Policy delegation and cascading</title>
- <para>Whenever a control policy is invoked it is given the opportunity to
change the response sent
+ <para>Whenever a control policy is invoked it is possible to change the
response sent
by the control flow. If the control policy ignores the error then the next
policy will handle the error
at this turn. However if the control policy decides to provide a new response
then the next policy
will not be invoked since the new response will not be of type error. For
instance, if a portlet part of a
@@ -43,7 +43,7 @@
</sect2>
<sect2>
<title>Default policy</title>
- <para>The default policy applies when error are not handled at other
level. By default errors are translated
+ <para>The default policy applies when errors are not handled at other
level. By default errors are translated
into the most appropriate HTTP response:
<itemizedlist>
<listitem>Access denied: HTTP 403 Forbidden
response</listitem>
@@ -56,14 +56,14 @@
</sect2>
<sect2>
<title>Portal policy</title>
- <para>Portal error policy controls the response that will be sent to the
browser when an error occurs. There is a default
+ <para>The portal error policy controls the response that will be sent to
the browser when an error occurs. There is a default
configuration and it is reconfigurable per portal. Whenever an error occurs, the
policy can either handle a redirect to
a JSP page or ignore the error. If the error is ignored it will be handled by
the default policy, otherwise a JSP page
will be invoked with appropriate request attributes to allow page
customization.</para>
</sect2>
<sect2>
<title>Page policy</title>
- <para>Window error policy controls how the page reacts to aggregation
errors. Indeed the page is most of the
+ <para>The window error policy controls how the page reacts to aggregation
errors. Indeed the page is most of the
time an aggregation of several portlet windows and the action to take when an
error occurs is different than
the other policies. Whenever an error occurs, the policy can either handle it
or ignore it. If the error is
ignored then it will be treated by the portal policy. The different actions
that are possible upon an error are:
@@ -266,8 +266,8 @@
<title>Handling errors with JSP</title>
<para>As described above it is possible to redirect error handling to a
JavaServer Page. Two pages can be created
to handle errors at portal and page level. Portal level error handling requires a
page that will produce a full
- page and the page level error handling requires a page that will producer markup
for a window only. When the page
- is invoked it will be passed a set of request attributes.</para>
+ page and the page level error handling requires a page that will produce markup for
a window only. When the page
+ is invoked a set of request attributes will be passed.</para>
<para>
<table frame="all">
<title>Request attributes</title>
Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/identity.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/identity.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/identity.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -774,7 +774,7 @@
</programlisting>
Configuration file contains properties definition that can be retrieved using
the <emphasis role="bold">PropertyInfo</emphasis> interface.
Each property used in portal has to be defined here.
- <note>Some information provided here can have a large impact on the
behaviour of the UserProfileModule. For instance
+ <note>Some information provided here can have a large impact on the
behavior of the UserProfileModule. For instance
<emphasis>access-mode</emphasis> can be made read-only and the value
provided in <emphasis>type</emphasis> will be checked
during <emphasis>setProperty()/getProperty()</emphasis> operations.
On the other hand tags like <emphasis>usage</emphasis>,
<emphasis>description</emphasis> or
<emphasis>display-name</emphasis> have mostly informational meaning at the
moment and
@@ -812,7 +812,7 @@
Also even when using LDAP some properties will be mapped to LDAP and some
to database. Its because LDAP schema doesn't support all attributes proper
to for portal properties. To solve this we have <emphasis
role="bold">DelegatingUserProfileModuleImpl</emphasis> that will
delegate method invocation to
<emphasis>ldap</emphasis> or
<emphasis>database</emphasis> related
<emphasis>UserProfile</emphasis> module. When
<emphasis>LDAP</emphasis> support is enabled and
- property need to be stored in database user will be synchronized into
database when needed. This behaviour can be configured.</note>
+ property need to be stored in database user will be synchronized into
database when needed. This behavior can be configured.</note>
</listitem>
</itemizedlist>
@@ -858,10 +858,10 @@
</sect2>
<sect2 id="identity.management_api">
<title>Delegating UserProfile module</title>
- <para>Delegating UserProfileModule implementation has very specific role.
When we use storage mechanism like LDAP we may not be able to map all
+ <para>Delegating UserProfileModule implementation has very specific role.
When we use a storage mechanism like LDAP we may not be able to map all
user properties into LDAP attributes because of schema limitations. To solve
this problem we still can use the database to store user properties
that do not exist in the LDAP schema.
- Delegating user profile module will recognize if a property is mapped as
<emphasis role="bold">ldap</emphasis> or <emphasis
role="bold">database</emphasis>
+ The Delegating user profile module will recognize if a property is mapped as
<emphasis role="bold">ldap</emphasis> or <emphasis
role="bold">database</emphasis>
and delegate <emphasis>setProperty()/getProperty()</emphasis> method
invocation to proper module implementation. This is implemented in
<emphasis
role="bold">org.jboss.portal.identity.DelegatingUserProfileModuleImpl</emphasis>.
If property is mapped either as
<emphasis role="bold">ldap</emphasis> and <emphasis
role="bold">database</emphasis> the <emphasis
role="bold">ldap</emphasis> mapping will
@@ -911,9 +911,9 @@
</sect2>
<sect2>
<title>Database UserProfile module implementation</title>
- <para>Because of the behaviour described in the previous section, database
UserProfileModule requires some special features. If a user is present in
+ <para>Because of the behavior described in the previous section, database
UserProfileModule requires some special features. If a user is present in
LDAP server but a writable property isn't mapped as an LDAP attribute, such
property requires to be stored in the database. In order to achieve
- such result the user need to be synchronized from ldap into the database
first.</para>
+ such result the user need to be synchronized from LDAP into the database
first.</para>
<para>Class
<emphasis>org.jboss.portal.identity.db.HibernateUserProfileModuleImpl</emphasis>
has additional synchronization features.
Here are the options:
<itemizedlist>
Modified:
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/identityportlets.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/identityportlets.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/identityportlets.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -38,7 +38,7 @@
creation of the new account. (Disabled by default,see <xref
linkend="identity_portlet_configuration_jbpm"/>)</para>
</listitem>
<listitem>
- <para>Captcha support: The users are prompted to copy letters from a deformed
image. (Enabled by default, see <xref
linkend="identity_portlet_configuration_captcha"/>)</para>
+ <para>Captcha support: The users are prompted to copy letters from a deformed
image. (Disabled by default, see <xref
linkend="identity_portlet_configuration_captcha"/>)</para>
</listitem>
<listitem>
<para>Lost password: The users can receive a new password by email, any user
with access to the admin portlet can also reset another user's password and send the
new one by email in one click. (Disabled by default, see <xref
linkend="identity_portlet_configuration_lost_password"/>)</para>
@@ -173,8 +173,7 @@
<sect2 id="identity_portlet_configuration_jbpm">
<title>jBPM based user registration</title>
<para>
- JBoss Portal supports by default three different
- subscription modes:
+ JBoss Portal supports three different subscription modes by default:
<itemizedlist>
<listitem>
<para>Automatic subscription (no jBPM required), the users can register and
directly login.</para>
@@ -245,8 +244,7 @@
<emphasis role="bold">
subscription-mode:
</emphasis>
- defines the User Portlet registration
- process
+ defines the User Portlet registration process
<itemizedlist>
<listitem>
<emphasis>automatic:</emphasis> no validation nor approval
(default)
@@ -649,7 +647,7 @@
<emphasis role="bold">
converter
</emphasis>
- - references the name of aregistered JSF converter<sbr />
+ - references the name of a registered JSF converter<sbr />
example: <emphasis>metadataservice.gender.converter</emphasis>
<programlisting><![CDATA[<f:converter
converterId="#{metadataservice.gender.converter}"/>]]></programlisting>
</para>
@@ -673,8 +671,7 @@
<para>The values of the profile-config.xml have a higher
priority than the values in the user portlet
configuration. That means if the 'usage' is 'mandatory'
- in
- <emphasis>profile-config.xml</emphasis>
+ in <emphasis>profile-config.xml</emphasis>
and 'required' is 'false' it will be overwritten by the
value from the profile config!</para>
</warning>
Modified:
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/installation.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/installation.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/installation.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -89,8 +89,8 @@
<sect3>
<title>Application Server Setup</title>
<para>Of course you will need to install JBoss Application Server prior
to installing JBoss
- portal, if you didn't do so yet, please install JBoss EAP 4.2 or JBoss
AS 4.2.2. If you have a
- subscription contract with Red Hat, can have access to the EAP
+ Portal, if you didn't do so yet, please install JBoss EAP 4.2 or JBoss
AS 4.2.2. If you have a
+ subscription contract with Red Hat, you can have access to the EAP
version from the <ulink
url="http://network.jboss.com/">support portal</ulink>.
For the other versions you can get them
<ulink
url="http://labs.jboss.com/portal/jbossas/download/index.html"&...
.
@@ -262,7 +262,7 @@
<title>Application Server Setup</title>
<para>Of course you will need to install JBoss Application Server prior
to installing JBoss
portal, if you didn't do so yet, please install JBoss EAP 4.2 or JBoss
AS 4.2.2. If you have a
- subscription contract with Red Hat, can have access to the EAP
+ subscription contract with Red Hat, you can have access to the EAP
version from the <ulink
url="http://network.jboss.com/">support portal</ulink>.
For the other versions you can get them
<ulink
Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/ldap.xml
===================================================================
--- docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/ldap.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++ docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/ldap.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -531,7 +531,7 @@
</itemizedlist>
</para>
</sect3>
- <note>In <emphasis>UserModule</emphasis> there are two methods
that handle offset/limit (pagination) behaviour.
+ <note>In <emphasis>UserModule</emphasis> there are two methods
that handle offset/limit (pagination) behavior.
<programlisting>
<![CDATA[
/** Get a range of users.*/
Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/migration.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/migration.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/migration.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -516,7 +516,7 @@
</listitem>
</itemizedlist>
</para>
- <para>Which should lead to a successfull end :)
+ <para>Which should lead to a successful end :)
<imageobject>
<imagedata align="center" valign="middle"
fileref="images/migration/migration_app_11.jpg"/>
</imageobject>
Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portalapi.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portalapi.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portalapi.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -24,7 +24,7 @@
of this API are prefixed with this package name except for the
<emphasis>org.jboss.portal.Mode</emphasis>
and <emphasis>org.jboss.portal.WindowState</emphasis> classes. These
two classes were defined before the official
Portal API framework was created and so the names have been maintained for
backward compatibility.</para>
- <para>The Portlet API defines two classes that represents a portion of the
visual state of a Portlet which
+ <para>The Portlet API defines two classes that represent a portion of the
visual state of a Portlet which
are <emphasis>javax.portlet.PortletMode</emphasis> and
<emphasis>javax.portlet.WindowState</emphasis>. Likewise
the Portal API defines similar classes named
<emphasis>org.jboss.portal.Mode</emphasis> and
<emphasis>org.jboss.portal.WindowState</emphasis> which offer
comparable characteristics, the main differences are:</para>
@@ -71,7 +71,7 @@
to access the URL, if the argument value is false then the user should not be
authenticated. Finally if the argument value is
null then it means that the URL authenticated mode should reuse the current
mode.</listitem>
<listitem>The <emphasis>setSecure(Boolean
wantSecure)</emphasis> methods defines the same as above but for the
- transport guarantee offered by the underlying protocol which means most of the
time the secure HTTP protocol.</listitem>
+ transport guarantee offered by the underlying protocol which means most of the
time the secure HTTP protocol (HTTPS).</listitem>
<listitem>The <emphasis>setRelative(boolean
relative)</emphasis> defines the output format of the URL and
whether the created URL will be an URL relative to the same web server or will
be the full URL.</listitem>
<listitem>The <emphasis>toString()</emphasis> method will
create the URL as a string.</listitem>
@@ -230,14 +230,14 @@
Listeners declaration requires a service to be deployed in JBoss that will
instantiate the service implementation
and register it with the service registry. We will see how to achieve that in
the example section of this chapter.
</para>
- <important>
+ <note>
The event propagation model uses one instance of a listener class to receive all
portal events that
may be routed to that class when appropriate. Therefore implementors needs to be
aware of that model
- and must provide implementations that are thread safe.
- </important>
+ and must provide <emphasis role="bold">thread
safe</emphasis> implementations.
+ </note>
<sect2>
<title>Portal node events</title>
- <para>Portal node events extends the abstract portal event framework in
order to provide notifications
+ <para>Portal node events extend the abstract portal event framework in
order to provide notifications
about user interface events happening at runtime. For instance when the portal
renders a page or a window,
a corresponding event will be fired.</para>
<mediaobject>
@@ -310,7 +310,7 @@
<para>The
<emphasis>org.jboss.portal.api.node.event.PortalNodeEventContext</emphasis>
interface extends
the <emphasis>PortalEventContext</emphasis> interface and plays
an important role
in the event delivery model explained in the previous section. That interface
gives full control over the
- delivery of the event to ascendant nodes in the hierarchy, even more it gives
the possiblity to replace
+ delivery of the event to ascendant nodes in the hierarchy, even more it gives
the possibility to replace
the current event being delivered by a new event that will be transformed
into the corresponding portal
behavior. However there are no guarantees that the portal will turn the
returned event into a portal
behavior, here the portal provides a best effort policy, indeed sometime it
is not possible to achieve
@@ -416,8 +416,8 @@
On this method we simply filter down to UserAuthenticationEvent then depending
on the type of authentication event we update the
counters. <emphasis>counter</emphasis> keeps track of the registered
and logged-in users, while counterEver only counts the number of
times people logged-in the portal.</para>
- <para>Now that the Java class has been written we need to register it so
that it can be actionned when the events are triggered. To do
- so we need to register it as an mbean. It can be done by editing the sar
descriptor file:
+ <para>Now that the Java class has been written we need to register it so
that it can be called when the events are triggered. To do
+ so we need to register it as an MBean. It can be done by editing the sar
descriptor file:
<emphasis>YourService.sar/META-INF/jboss-service.xml</emphasis> so
that it looks like the following:
<programlisting><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
@@ -452,13 +452,13 @@
</listitem>
</itemizedlist>
</para>
- <para>That's it we now have a user counter that will display it states
each time a user logs-in our logs-out.</para>
+ <para>That's it - we now have a user counter that will display it
states each time a user logs-in our logs-out.</para>
</sect2>
<sect2>
<title>Achieving Inter Portlet Communication with the events
mechanism</title>
<para>The first version of the Portlet Specification (JSR 168),
regretfully, did not cover interaction between
portlets. The side-effect of diverting the issue to the subsequent release of
the specification, has
- forced portal vendors to each craft their own proprietary API to achieve
interportlet communication. Here we will
+ forced portal vendors to each craft their own proprietary API to achieve inter
portlet communication. Here we will
see how we can use the event mechanism to pass parameters from one portlet to
the other (and only to the other portlet).</para>
<para>The overall scenario will be that Portlet B will need to be updated
based on some parameter set on Portlet A.
To achieve that we will use a portal node event.</para>
Modified:
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portletmodes.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portletmodes.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portletmodes.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -8,19 +8,19 @@
</author>
</chapterinfo>
<title>Portlet Modes</title>
- <para>JBoss Portal suppors the standard portlets modes mandated by the JSR-168
specification which are <emphasis>view</emphasis>,
+ <para>JBoss Portal supports the standard portlet modes defined by the JSR-168
specification which are <emphasis>view</emphasis>,
<emphasis>edit</emphasis> and <emphasis>help</emphasis>. In
addition of that it also supports the <emphasis>admin</emphasis>
portlet mode.
</para>
<sect1>
<title>Admin Portlet Mode</title>
- <para>The admin mode defines a mode for the portlet which allow
administration of the portlet. Its access
+ <para>The admin mode defines a mode for the portlet which allows the
administration of the portlet. Access to this mode
is only granted to users having an appropriate role. In order to grant admin access
to a portlet, the user must have a role which
grants him the <emphasis>admin</emphasis> action permission on the
portlet instance. This can be done in the
instance deployment descriptor or using the administation portlet of the portal.
</para>
<sect2>
<title>Portlet configuration</title>
- <para>In order to be able to use the admin mode, the portlet must declares
it in the portlet deployment descriptor.</para>
+ <para>In order to be able to use the admin mode, the portlet must declare
it in the portlet deployment descriptor.</para>
<programlisting><![CDATA[
<portlet-app>
...
@@ -43,7 +43,7 @@
<sect2>
<title>Declarative instance security configuration</title>
<para>The following example shows the configuration of a portlet instance
that grants the admin action permission
- to the <emphasis>Admin</emphasis> security role. It also grant
the view action permission to all users.
+ to the <emphasis>Admin</emphasis> security role. It also grants
the view action permission to all users.
</para>
<programlisting><![CDATA[
...
Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/security.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/security.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/security.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -307,7 +307,7 @@
<title>Authentication with JBoss Portal</title>
<para>JBoss Portal relies on Java EE for the authentication of users. The
Java EE authentication has its advantages
and drawbacks. The main motivation for using Java EE security is the integration
with the application server and the
- operational environment in which the portal is deployed. The servlet layer provides
already the authentication functionnality
+ operational environment in which the portal is deployed. The servlet layer provides
already the authentication functionality
and obviously it is not a responsibility of the portal. Whenever a user is
authenticated by the servlet layer
its security identity is propagated throughout the call stack in the different
layers of the Java EE stack. The weaknesses
are the lack of an explicit logout mechanism and the lack of dynamicity in the
mapping of URL as security resources. However
@@ -329,7 +329,7 @@
and is dynamically deployed with the portal. The JBoss Application Server
documentation is certainly the best
reference for that topic.
</listitem>
- <listitem>The files <emphasis>login.jsp</emphasis> and
<emphasis>error.jsp</emphasis> provide the pages used
+ <listitem>The files <emphasis>login.jsp</emphasis> and
<emphasis>error.jsp</emphasis> represent the pages used
the form based authentication process. More information can be found in
any good servlet documentation.</listitem>
</itemizedlist>
</para>
@@ -355,7 +355,7 @@
about it.</listitem>
<listitem><emphasis>/auth/*</emphasis> : the
authenticated access, requires the user to be authenticated
to be used.</listitem>
- <listitem><emphasis>/authsec/*</emphasis> : combine thet
two previous options into a single one.</listitem>
+ <listitem><emphasis>/authsec/*</emphasis> : combine the
two previous options into a single one.</listitem>
</itemizedlist>
Usually ones should not care much about those mappings as the portal will by
itself switch to the most appropriate mapping.
</para>
@@ -399,7 +399,7 @@
<listitem><emphasis>org.jboss.portal.security.spi.provider.DomainConfigurator</emphasis>
provides configuration access
to an authorization domain. The authorization schema is very simple as it
consists of bindings between URI, roles and permissions.</listitem>
<listitem><emphasis>org.jboss.portal.security.spi.provider.PermissionRepository</emphasis>
provides runtime access to the authorization
- domain. Usually it is used to retrieves the permissions for a specific
role and URI. It is used at runtime by the framework
+ domain. Usually it is used to retrieve the permissions for a specific role
and URI. It is used at runtime by the framework
to take security decisions.</listitem>
<listitem><emphasis>org.jboss.portal.security.spi.provider.PermissionFactory</emphasis>
is a factory to instantiate permissions
for the specific domain. It is used at runtime to create permissions
objects of the appropriate type by the security framework.</listitem>
Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/sso.xml
===================================================================
--- docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/sso.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++ docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/sso.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -154,7 +154,7 @@
<title>Integration steps</title>
<note>The steps below assume that CAS server and JBoss Portal will be
deployed on the same JBoss Application Server instance.
CAS will be configured to leverage identity services exposed by JBoss Portal
to perform authentication. Procedure may be
- sligtly different for other deployment scenarios. Both JBoss Portal and CAS
will need to be configured to authenticate against
+ slightly different for other deployment scenarios. Both JBoss Portal and CAS
will need to be configured to authenticate against
same database or LDAP server. Please see CAS documentation to learn how to
setup it up against proper identity store.</note>
<note>Configuration below assumes that JBoss Application Server is HTTPS
enabled and operates on standard ports: 80 (for HTTP) and 443 (for HTTPS).</note>
@@ -264,7 +264,7 @@
<listitem>Click on the "Login" link on the main portal
page</listitem>
<listitem>This should bring up the CAS Authentication Server's
login screen instead of the default JBoss Portal login screen</listitem>
<listitem>Input your portal username and password. For built-in
portal login try user:user or admin:admin</listitem>
- <listitem>If login is successfull, you should be redirected back to
the portal with the appropriate user logged in</listitem>
+ <listitem>If login is successful, you should be redirected back to
the portal with the appropriate user logged in</listitem>
</itemizedlist>
</para>
</sect2>
@@ -275,7 +275,7 @@
<ulink
url="http://www.josso.org/">here</ulink></para>
<note>The steps below assume that JOSS server and JBoss Portal will be
deployed on the same JBoss Application Server instance.
JOSSO will be configured to leverage identity services exposed by JBoss Portal
to perform authentication. Procedure may be
- sligtly different for other deployment scenarios. Both JBoss Portal and JOSSO
will need to be configured to authenticate against
+ slightly different for other deployment scenarios. Both JBoss Portal and JOSSO
will need to be configured to authenticate against
same database or LDAP server. Please see JOSSO documentation to learn how to
setup it up against proper identity store.</note>
<note>Configuration below assumes that JOSSO is already installed and
deployed in the JBoss Application Server. This involves adding proper jar files
into the classpath and altering several configuration files (adding tomcat
valves, security realm and specific JOSSO configuration files).
@@ -366,7 +366,7 @@
</mbean>
]]>
</programlisting>
- This will expose special service in JBoss Portal that can be leveraged by
JOSSO Credential and Identity Stores if the server is deployed on the same
+ This will expose a special service in JBoss Portal that can be leveraged
by JOSSO Credential and Identity Stores if the server is deployed on the same
application server instance.
</listitem>
<listitem>
@@ -437,7 +437,7 @@
<listitem>Click on the "Login" link on the main portal
page</listitem>
<listitem>This should bring up the JOSSO login screen instead of
the default JBoss Portal login screen</listitem>
<listitem>Input your portal username and password. For built-in
portal login try user:user or admin:admin</listitem>
- <listitem>If login is successfull, you should be redirected back to
the portal with the appropriate user logged in</listitem>
+ <listitem>If login is successful, you should be redirected back to
the portal with the appropriate user logged in</listitem>
</itemizedlist>
</para>
</sect2>
Modified:
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/themeandlayouts.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/themeandlayouts.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/themeandlayouts.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -31,8 +31,8 @@
responsible to render markup that will wrap the markup fragments produced by the
individual
portlets. Themes, on the other hand, are responsible to style and enhance this
markup.
</para>
- <para>In JBoss Portal, layouts are implemented as a JSP or a Servlet. Themes
are implemeted
- using CSS Style sheets, javascript and images. The binding elemement between
layouts and
+ <para>In JBoss Portal, layouts are implemented as a JSP or a Servlet. Themes
are implemented
+ using CSS Style sheets, javascript and images. The binding element between
layouts and
themes are the class and id attributes of the rendered markup.
</para>
<para>JBoss Portal has the concept of regions on a page. When a page is
defined, and portlet
@@ -57,7 +57,7 @@
of classes
</listitem>
</itemizedlist>
- In JBoss Portal you can currently see two out of these approaches, namley
+ In JBoss Portal you can currently see two out of these approaches, namely
the first and the last. Examples for the first can be found in the
portal-core.war,
implemented by the nodesk and phalanx layouts. Examples for the third approach
can be found
in the same war, implemented by the industrial and Nphalanx layout. What
encapsulates the
@@ -95,7 +95,7 @@
</para>
-->
<para>The last topic to introduce in this overview is the one of portal
themes. A theme is a
- collection of web design artifacts. It defines a set of css, java script and
image files
+ collection of web design artifacts. It defines a set of CSS, javascript and
image files
that together decide about the look and feel of the portal page. The theme can
take a wide
spectrum of control over the look and feel. It can limit itself to decide fonts
and colors,
or it can take over a lot more and decide the placement (location) of portlets
and much
@@ -119,7 +119,7 @@
<imagedata fileref="images/themeguide/portal-header.gif"
format="gif"/>
</imageobject>
<caption>
- <para>Scheenshot of the header with the 'renaissance'
theme</para>
+ <para>Screenshot of the header with the 'renaissance'
theme</para>
</caption>
</mediaobject>
<note>Here, we use split content from rendering by using a CSS style
sheet, it allow us to change the
@@ -164,7 +164,7 @@
optional-attribute-name="PortalAuthorizationManagerFactory"
proxy-type="attribute">portal:service=PortalAuthorizationManagerFactory</depends>
</mbean>]]></programlisting>
- The three attibutes are:
+ The three attributes are:
<itemizedlist>
<listitem>TargetContextPath: Defines the web application context
where the JSPs are located</listitem>
<listitem>HeaderPath: Defines the location (in the web
application previously defined) of the JSP in charge of writing the header
links</listitem>
@@ -326,7 +326,7 @@
</para>
</sect3>
<sect3>
- <title>Programatic use</title>
+ <title>Programmatic use</title>
<para>To access a layout from code, you need to get a reference to the
LayoutService
interface. The layout service is an mbean that allows access to the
PortalLayout
interface for each layout that was defined in a portal layout descriptor.
As a layout
@@ -343,7 +343,7 @@
folder of the deployed portal application. Note that this is not limited to
the
portal-core.war, but can be added to any WAR that you deploy to the same
server. The
Portal runtime will detect the deployed application and introspect the
WEB-INF folder
- for known descriptors like the two metioned here. If present, the appropriate
meta data
+ for known descriptors like the two mentioned here. If present, the
appropriate meta data
is formed and added to the portal runtime. From that time on the resources in
that
application are available to be used by the portal. This is an elegant way
to
dynamically add new layouts or themes to the portal without having to bring
down , or
@@ -435,7 +435,7 @@
<title>The theme tag</title>
<para>The theme tag looks for the determined theme of the current
request (see
Portal Themes for more details). If no theme was determined, this tag
allows an
- optional attribute 'themeName' that can be used to specifiy a
default theme to use
+ optional attribute 'themeName' that can be used to specify a
default theme to use
as a last resort. Based on the determined theme name, the ThemeService
is called
to lookup the theme with this name and to get the resources associated
with this
theme. The resulting style and link elements are injected, making sure
that war
@@ -456,7 +456,7 @@
individual portlet markup fragments. The regionName attribute functions
as a query
param into the current page. It determines from what page region the
portlets will
be rendered in this tag. The regionID attribute is what the RenderSet
can use to
- generate a css selector for this particular region. In case of the
divRenderer, a
+ generate a CSS selector for this particular region. In case of the
divRenderer, a
DIV tag with an id attribute corresponding to the provided value will
be rendered
for this region. This id in turn can be picked up by the CSS to style
the region.
</para>
@@ -625,7 +625,7 @@
between the layout and the theme that takes the information available in the
portal and
renders markup containing the current state of the page and each portlet on
it. It makes
sure that the markup around each region and portlet contains the selectors
that the
- theme css needs to style the page content appropriately.
+ theme CSS needs to style the page content appropriately.
</para>
<para>A RenderSet consists of the implementations of four interfaces. Each
of those
interfaces corresponds to a markup container on the page.
@@ -745,7 +745,7 @@
<uri state="maximized">/generic/maximized.jsp</uri>
</layout>
</layouts>]]></programlisting>
- Again, anologous to layout strategies, the anonymous RenderSet
+ Again, analogous to layout strategies, the anonymous RenderSet
overwrites the one specified for the page, and that overwrites the one
specified for the
portal. In other words: all pages that use the layout that defines an
anonymous
RenderSet will use that RenderSet, and ignore what is defined as RenderSet
for the
@@ -793,14 +793,14 @@
<title>What is a Theme</title>
<para>A portal theme is a collection of CSS styles, JavaScript files, and
images, that all
work together to style and enhance the rendered markup of the portal page.
The theme
- works together with the layout and the RenderSet in procuding the content and
final look
+ works together with the layout and the RenderSet in producing the content and
final look
and feel of the portal response. Through clean separation of markup and
styles a much
- more flexible and powerfull approach to theming portals is possible. While
this approach
+ more flexible and powerful approach to theming portals is possible. While
this approach
is not enforced, it is strongly encouraged. If you follow the definitions of
the
Theme Style Guide (see later), it is not necessary to change the layout or
the strategy,
or the RenderSet to achieve very different look and feels for the portal. All
you need
to change is the theme. Since the theme has no binary dependencies, it is
very simple to
- swapt it, or change individual items of it. No compile or redeploy is
necessary. Themes
+ swap, or change individual items of it. No compile or redeploy is necessary.
Themes
can be added or removed while the portal is active. Themes can be deployed in
separate
web applications furthering even more the flexibility of this approach. Web
developers
don't have to work with JSPs. They can stay in their favorite design tool
and simple
@@ -880,7 +880,7 @@
</theme>
</themes>]]></programlisting>
</para>
- <para>Themes are defined in the portal-themes.xml theme descriptor, which
is localted in
+ <para>Themes are defined in the portal-themes.xml theme descriptor, which
is located in
the WEB-INF/ folder of the web application.
</para>
</sect2>
@@ -974,7 +974,7 @@
</body>
</html>]]></programlisting>
For the function of the individual tags in this example, please
- refere to the layout section of this document.
+ refer to the layout section of this document.
</para>
</sect2>
<sect2>
@@ -998,7 +998,7 @@
result of this, the token to use for rewrite is the WSRP specified
"wsrp_rewrite_". If
the portlet sets the following response property
<programlisting>res.setProperty("WSRP_REWRITE","true");</programlisting>
- all occurences
+ all occurrences
of the wsrp_rewrite_ token in the portlet fragment will be replaced with a
unique token
(the window id). If the portlet also specifies content to be injected into
the header of
the page, that content is also subject to this rewrite.
@@ -1045,7 +1045,7 @@
requires the layout JSP to add the "headerContent" JSP tag (see
example above). One thing to note here is
the order of the tags. If the headerContent tag is placed after the theme
tag, it will allow portlet
injected
- CSS files to overwrite the theme's behaviour, making this feature even
more powerful!
+ CSS files to overwrite the theme's behavior, making this feature even
more powerful!
</para>
</sect2>
<sect2>
@@ -1077,8 +1077,8 @@
<title>Theme Style Guide (based on the Industrial theme)</title>
<sect2>
<title>Overview</title>
- <note>This section to be updated soon with new CSS selectors found in
JBoss Portal 2.6. The cuirrent
- definititions remain, but the newer additions with regards to
dashboards/drag-n-drop have not been
+ <note>This section to be updated soon with new CSS selectors found in
JBoss Portal 2.6. The current
+ definitions remain, but the newer additions with regards to
dashboards/drag-n-drop have not been
documented as of yet.
</note>
<para>This document outlines the different selectors used to handle the
layout and
Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/tutorials.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/tutorials.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/tutorials.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -50,7 +50,7 @@
extend those modes. The 3 modes are:
<itemizedlist>
<listitem>VIEW - Generates markup reflecting the current state of
the portlet.</listitem>
- <listitem>EDIT - Should allow a user to customize the behaviour of
the portlet.</listitem>
+ <listitem>EDIT - Should allow a user to customize the behavior of
the portlet.</listitem>
<listitem>HELP - Should provide some information to the user as to
how to use the portlet.</listitem>
</itemizedlist>
</para>
@@ -295,7 +295,7 @@
</portlet-info>
]]></programlisting>
The portlet's title will be displayed as the header
in the portlet window, when
- rendered, unless it is overridden programatically.
+ rendered, unless it is overridden programmatically.
</para>
</listitem>
</itemizedlist>
Added:
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/widgetintegration.xml
===================================================================
--- docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/widgetintegration.xml
(rev 0)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/widgetintegration.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -0,0 +1,87 @@
+<chapter id="widgets">
+ <chapterinfo>
+ <author>
+ <firstname>Emanuel</firstname>
+ <surname>Muckenhuber</surname>
+ <email>emuckenh(a)redhat.com</email>
+ </author>
+ </chapterinfo>
+ <title>Widget Integration</title>
+ <sect1>
+ <title>Introduction</title>
+ <para>JBoss Portal supports the integration of Google gadgets and Netvibes
(<ulink
url="http://dev.netvibes.com/doc/uwa_specification">UWA</...
compatible)
+ widgets out of the box. This integration allows you to display the content of
the widget within a portlet.
+ Both types can be added in the administration interface by editing the 'Page
Layout' of a page or in the configuration of the users dashboard
+ when selecting the appropriate 'Content type'.
+ </para>
+ </sect1>
+ <sect1>
+ <title>Widget portlet configuration</title>
+ <para>It is possible to modify certain behavior of caching and fetching
widgets by changing the init-param values of the portlet.</para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <emphasis role="bold">connectionTimeout</emphasis>
+ <para>
+ Connection timeout used for the directory lookup in milliseconds.
+ </para>
+ </listitem>
+ <listitem>
+ <emphasis role="bold">widgetExpiration</emphasis>
+ <para>
+ Time in minutes for which a widget should be cached. After this time the
cached widget information will be deleted and
+ fetched again when the information are needed.
+ </para>
+ </listitem>
+ <listitem>
+ <emphasis role="bold">queryExpiration</emphasis>
+ <para>
+ Times in minutes for which a directory query should be cached. After
this time the cached query information will be deleted.
+ </para>
+ </listitem>
+ <listitem>
+ <emphasis
role="bold">fetchWidgetsOnDirectoryLookup</emphasis>
+ <para>
+ This parameter defines if all widgets from a directory lookup should be fetched
at the time of the query or not.
+ The default values is false. This means that widgets are only fetched on demand -
when the information is really needed.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ The parameter for both widget types can be changed identically in either:
+ <itemizedlist>
+
<listitem><emphasis>jboss-portal.sar/portal-widget.war/WEB-INF/portlet.xml</emphasis>
(for google gadgets)</listitem>
+ <listitem>or
<emphasis>jboss-portal.sar/portal-widget-netvibes.war/WEB-INF/portlet.xml</emphasis>
(for netvibes widgets).</listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ <programlisting><![CDATA[...
+ <portlet>
+ ...
+ <init-param>
+ <name>connectionTimeout</name>
+ <value>5000</value>
+ </init-param>
+ <init-param>
+ <name>widgetExpiration</name>
+ <value>360</value>
+ </init-param>
+ <init-param>
+ <name>queryExpiration</name>
+ <value>60</value>
+ </init-param>
+ <init-param>
+ <name>fetchWidgetsOnDirectoryLookup</name>
+ <value>false</value>
+ </init-param>
+ ...
+ </portlet>
+...]]></programlisting>
+ </para>
+ <para>
+ For Netvibes widgets it is also possible to define a init-param called <emphasis
role="bold">defaultHeight</emphasis> to set a specific
+ default height if no height attribute is defined by the widget itself. The default
value is 250.
+ </para>
+ </sect1>
+</chapter>
Modified:
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/xmldescriptors.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/xmldescriptors.xml 2007-11-28
14:18:08 UTC (rev 9167)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/xmldescriptors.xml 2007-11-28
15:41:20 UTC (rev 9168)
@@ -1185,7 +1185,7 @@
<sect2 id="descriptor_debug">
<title>Portlet Debugging (jboss-portal.sar/conf/config.xml)</title>
<para>
- By default, JBoss Portal ships with all errors set to display. You can
fine-tune this behaviour by modifying
+ By default, JBoss Portal ships with all errors set to display. You can
fine-tune this behavior by modifying
some properties in the file,
<emphasis>jboss-portal.sar/conf/config.xml</emphasis>
: