[portal-commits] JBoss Portal SVN: r9168 - in docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en: modules and 1 other directory.

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 &lt;portlet-refresh&gt;false&lt;portlet-refresh&gt; 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&gt;emuckenh(a)redhat.com&lt;/email&gt; + </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> :