Author: ekopalov Date: 2012-10-12 11:54:27 -0400 (Fri, 12 Oct 2012) New Revision: 8885 Modified: epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DataImportStrategy.xml epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/NavigationController.xml epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/configuration.xml epp/docs/branches/5.2/Reference_Guide/en-US/modules/WSRP.xml Log: partial fix of BZ 850885; until comment 3: community links Modified: epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DataImportStrategy.xml =================================================================== --- epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DataImportStrategy.xml 2012-10-12 15:25:08 UTC (rev 8884) +++ epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DataImportStrategy.xml 2012-10-12 15:54:27 UTC (rev 8885) @@ -8,7 +8,7 @@ <section id="sect-Reference_Guide-Data_Import_Strategy-Introduction"> <title>Introduction</title> <para> - In the Portal extension mechanism, developers can define an extension that Portal data can be customized by configurations in the extension. There are several cases which an extension developer wants to define how to customize the Portal data, for example modifying, overwriting or just inserting a bit into the data defined by the portal. Therefore, GateIn also defines several modes for each case and the only thing which a developer has to do is to clarify the use-case and reasonably configure extensions. + In the Portal extension mechanism, developers can define an extension that Portal data can be customized by. There are several cases when it is useful to be able to define how to customize the Portal data; for example modifying, overwriting or just inserting data into the data defined by the Portal. Therefore, GateIn also defines several modes for each case so that the developer only need to clarify the use-case and configure the extensions. </para> <para> This section shows you how data are changes in each mode. @@ -34,7 +34,7 @@ <section id="sect-Reference_Guide-Data_Import_Strategy-Portal_Config"> <title>Portal Configuration</title> <para> - PortalConfig defines the portal name, permission, layout and some properties of a site. These information are configured in the <emphasis>portal.xml</emphasis>, <emphasis>group.xml</emphasis> or <emphasis>user.xml</emphasis>, depending on the site type. The PortalConfig importer performs a strategy that is based on the mode defined in NewPortalConfigListener, including <literal>CONSERVE</literal>, <literal>INSERT</literal>, <literal>MERGE</literal> or <literal>OVERWRITE</literal>. Let&apos;s see how the import mode affects in the process of portal data performance: + PortalConfig defines the portal name, permission, layout and some properties of a site. These information are configured in the <emphasis>portal.xml</emphasis>, <emphasis>group.xml</emphasis> or <emphasis>user.xml</emphasis>, depending on the site type. The PortalConfig importer performs a strategy that is based on the mode defined in NewPortalConfigListener, including <literal>CONSERVE</literal>, <literal>INSERT</literal>, <literal>MERGE</literal> or <literal>OVERWRITE</literal>. Let&apos;s see how the import mode affects the process of portal data performance: </para> <itemizedlist> <listitem> @@ -57,18 +57,18 @@ <section id="sect-Reference_Guide-Data_Import_Strategy-Page_Data"> <title>Page Data</title> <para> - The import mode affects the page data import as the same as PortalConfig. + The import mode affects the page data import in the same way as PortalConfig. </para> <note> <para> - If the Import mode is <literal>CONSERVE</literal> or <literal>INSERT</literal>, the data import strategy always performs as the <literal>MERGE</literal> mode in the first data initialization of the Portal. - </para> + If the Import mode is <literal>CONSERVE</literal> or <literal>INSERT</literal>, the data import strategy acts as if in the <literal>MERGE</literal> mode in the first data initialization of the Portal. + </para> </note> </section> <section id="sect-Reference_Guide-Data_Import_Strategy-Navigation_Data"> <title>Navigation Data</title> <para> - The navigation data import strategy will be processed to the import mode level as the followings: + The navigation data import strategy is processed at the import mode level in the following way: </para> <itemizedlist> <listitem> @@ -78,12 +78,12 @@ </listitem> <listitem> <para> - <literal>INSERT</literal>: Insert the missing description data, but add only new nodes. Other modifications remains untouched. + <literal>INSERT</literal>: Insert the missing description data, but add only new nodes. Other modifications remain untouched. </para> </listitem> <listitem> <para> - <literal>MERGE</literal>: Merge the description data, add missing nodes and update same name nodes. + <literal>MERGE</literal>: Merge the description data, add missing nodes and update existing nodes. </para> </listitem> <listitem> Modified: epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml =================================================================== --- epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml 2012-10-12 15:25:08 UTC (rev 8884) +++ epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/DefaultPortalNavigationConfiguration.xml 2012-10-12 15:54:27 UTC (rev 8885) @@ -77,12 +77,12 @@ </callout> <callout arearefs="area-Reference_Guide-Portal_Navigation_Configuration-Overview-ownerType"> <para> - <parameter>ownerType</parameter> define the type of portal navigation. It may be a portal, group or user + <parameter>ownerType</parameter> defines the type of portal navigation. It may be a portal, group, or user. </para> </callout> <callout arearefs="area-Reference_Guide-Portal_Navigation_Configuration-Overview-templateLocation"> <para> - <parameter>templateLocation</parameter> the classpath where contains all portal configuration files + <parameter>templateLocation</parameter> defines the classpath to all portal configuration files </para> </callout> <callout arearefs="area-Reference_Guide-Portal_Navigation_Configuration-Overview-importMode"> @@ -117,7 +117,7 @@ Based on these parameters, the portal will look for the configuration files and create a relevant portal navigation, pages and data import strategy. </para> <para> - The portal configuration files will be stored in folders with path look like <filename>{templateLocation}/{ownerType}/{predefinedOwner}</filename>, all navigations are defined in the <filename>navigation.xml</filename> file, pages are defined in <filename>pages.xml</filename> and portal configuration is defined in <filename>portal.xml</filename>. + The portal configuration files are stored in the <filename>{templateLocation}/{ownerType}/{predefinedOwner}</filename> folder: navigations are defined in the <filename>navigation.xml</filename> file; pages are defined in <filename>pages.xml</filename>; portal configuration is defined in <filename>portal.xml</filename>. </para> <para> For example, with the above configuration, portal will look for all configuration files from <filename>war:/conf/portal/portal/classic path.</filename> @@ -160,10 +160,10 @@ This file defines all the navigation nodes the portal will have. The syntax is simple and uses nested node tags. Each node references a page defined in <filename>pages.xml</filename> file. </para> <!-- Updated based on Gatein revision 6987 --> <para> - If the administrator wants to create node labels for each language, they will have to use <literal>xml:lang</literal> attribute in the label tag with value of <literal>xml:lang</literal> is the relevant locale. + To create node labels for each language, define the <property>label</property> tag with the <literal>xml:lang</literal> attribute with the relevant locale value. </para> <para> - Otherwise, if they want the node label is localized by resource bundle files, the <literal>#{...}</literal> syntax will be used, the enclosed property name serves as a key that is automatically passed to internationalization mechanism which replaces the literal property name with a localized value taken from the associated properties file matching the current locale. + Otherwise, if you want the node label to be localized by resource bundle files, the <literal>#{...}</literal> syntax will be used, the enclosed property name serves as a key that is automatically passed to internationalization mechanism which replaces the literal property name with a localized value taken from the associated properties file matching the current locale. </para> <!-- DOC NOTE: Replaced code navigation.xml with code from GateIn commit r3831 (as per instruction from theute) --> <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/PortalDevelopment_DefaultPortalNavigationConfiguration/navigation.xml" parse="text"/></programlisting> <para> Modified: epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/NavigationController.xml =================================================================== --- epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/NavigationController.xml 2012-10-12 15:25:08 UTC (rev 8884) +++ epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/NavigationController.xml 2012-10-12 15:54:27 UTC (rev 8885) @@ -33,7 +33,7 @@ <section id="sect-Reference_Guide-Controller_in_Action-Controller"> <title>Controller</title> <para> - The <application>WebAppController</application> is the component of JBoss Enterprise Portal Platform that process <literal>http</literal> invocations and transforms them into a portal request. It has been improved with the addition of a request mapping engine (<emphasis role="bold">controller</emphasis>) whose role is to make the decoupling of the <literal>http</literal> request and create a portal request. + The <application>WebAppController</application> is the component of JBoss Enterprise Portal Platform that processes <literal>http</literal> invocations and transforms them into a portal request. It has been improved with the addition of a request mapping engine (<emphasis role="bold">controller</emphasis>) whose role is to make the decoupling of the <literal>http</literal> request and create a portal request. </para> <para> The mapping engine makes two essential tasks: @@ -54,7 +54,7 @@ The goal of the controller (mapping engine) is to <emphasis role="bold">decouple</emphasis> the request processed by JBoss Enterprise Portal Platform from the incoming <literal>HTTP</literal> request. </para> <para> - Indeed a request contain data that determines how the request will be processed and such data can be encoded in various places in the request such as the request path or a query parameter. The controller allows JBoss Enterprise Portal Platform route a request according to a set of parameters (a map) instead of the servlet request. + Indeed a request contains data that determines how the request will be processed and such data can be encoded in various places in the request such as the request path or a query parameter. The controller allows JBoss Enterprise Portal Platform route a request according to a set of parameters (a map) instead of the servlet request. </para> <para> The controller configuration is declarative in an XML file, allowing easy reconfiguration of the routing table and it is processed into an internal data structure that is used to perform resolution (routing or rendering) @@ -109,7 +109,7 @@ </listitem> <listitem> <para> - Operation findRoutes: route the request argument through the controller and returns a list of all parameter map resolution. The argument is a request uri such as <uri>/g/:platform:administrators/administration/registry</uri>. It returns a string representation (<code>List&lt;Map&gt;</code>) of the matched routes. + Operation findRoutes: routes the request argument through the controller and returns a list of parameter map resolution. The argument is a request URI such as <uri>/g/:platform:administrators/administration/registry</uri>. It returns a string representation (<code>List&lt;Map&gt;</code>) of the matched routes. </para> </listitem> </itemizedlist> @@ -117,32 +117,33 @@ <section id="sect-Reference_Guide-Controller_in_Action-Controller_Configuration_controller.xml"> <title>Controller Configuration (controller.xml)</title> <para> - Most of the controller configuration cares about defining rules (Routing table - contains routes object) that will drive the resolution. Routes are processed during the controller initialization to give a tree of node. Each node: </para> + Most of the controller configuration cares about defining rules (Routing table - contains routes object) that will drive the resolution. Routes are processed during the controller initialization to give a tree of nodea. For every node, the following is true: </para> <itemizedlist> <listitem> <para> - is related to its parent with a matching rule that can either be an <emphasis role="bold">exact string matching</emphasis> or a <emphasis role="bold">regular expression matching</emphasis> + It is related to its parent with a matching rule that can either be an <emphasis role="bold">exact string matching</emphasis> or a <emphasis role="bold">regular expression matching</emphasis> </para> </listitem> <listitem> <para> - is associated with a set of parameters + It is associated with a set of parameters. </para> </listitem> </itemizedlist> - <para> A parameter is defined by a qualified name and there are three kind of parameters: Route, Path, and Request. - </para> + <para> + A parameter is defined by a qualified name. There are three types of parameters: Route, Path, and Request. + </para> <section id="sect-Reference_Guide-Controller_Configuration_controller.xml-_Route_parameters_"> <title> <emphasis role="bold">Route parameters</emphasis> </title> <para> - Route parameters defines a fixed value associate with a qualified name. + The Route parameter defines a fixed value associated with a qualified name. </para> <itemizedlist> <listitem> <para> - Routing: route parameters allow the controller to distinguish branches easily and route the request accordingly. + Routing: route parameters allow the controller to distinguish branches and route the request accordingly. </para> </listitem> <listitem> @@ -277,12 +278,12 @@ <itemizedlist> <listitem> <para> - selection occurs for required parameters when is the parameter is present and matched in the map. + selection occurs for required parameters when the parameter is present and matched in the map. </para> </listitem> <listitem> <para> - selection occurs for optional parameters when is the parameter is absent or matched in the map. + selection occurs for optional parameters when the parameter is absent or matched in the map. </para> </listitem> </itemizedlist> @@ -302,7 +303,7 @@ <itemizedlist> <listitem> <para> - a <code>value</code> or a <code>pattern</code> element a child element to match a constant or a pattern + a <code>value</code> or a <code>pattern</code> element child element to match a constant or a pattern </para> </listitem> <listitem> @@ -320,7 +321,7 @@ <section id="sect-Reference_Guide-Controller_Configuration_controller.xml-Route_precedence"> <title>Route precedence</title> <para> - The order of route declaration is important as it influence how rules are matched. Sometimes the same request could be matched by several routes and the routing table is ambiguous. + The order of route declaration is important as it influences how rules are matched. Sometimes the same request could be matched by several routes and the routing table is ambiguous. </para> <programlisting language="XML"> &lt;route path=&quot;/foo&quot;&gt; @@ -397,7 +398,7 @@ <section id="sect-Reference_Guide-Integrate_to_JBoss_Enterprise_Portal_Platform_WebUI_framework-Routing"> <title>Routing</title> <para> - JBoss Enterprise Portal Platform defines a set of parameters in its routing table, for each client request, the mapping engine processes the request path and return the defined parameters with their values as a Map&lt;QualifiedName, String&gt; + JBoss Enterprise Portal Platform defines a set of parameters in its routing table: for each client request, the mapping engine processes the request path and returns the defined parameters with their values as a Map&lt;QualifiedName, String&gt; </para> <para> <emphasis role="bold">gtn:handler</emphasis> @@ -436,13 +437,13 @@ <emphasis role="bold">gtn:sitetype / gtn:sitename / gtn:path</emphasis> </para> <para> - Those qualified names drives a request for the portal handler. They are used to determine which site to show and which path to resolve against a navigation. For instance the (gtn:sitetype=portal,gtn:sitename=classic,gtn:path=home) instruct the portal handler to show the home page of the classic portal site. + The qualified names drive a request for the portal handler. They are used to determine which site to show and which path to resolve against a navigation. For instance the (gtn:sitetype=portal,gtn:sitename=classic,gtn:path=home) instruct the portal handler to show the home page of the classic portal site. </para> <para> <emphasis role="bold">gtn:lang</emphasis> </para> <para> - The language in the URL for the portal handler. This is a new feature offered, now language can be specified on URL. that mean user can bookmark that URL (with the information about language) or he can changed language simply by modifying the URL address + The language in the URL for the portal handler. This is a new feature offered, now language can be specified in a URL: user can bookmark the URL along with the information about the language or change the language by modifying the URL address. </para> <para> <emphasis role="bold">gtn:componentid / gtn:action / gtn:objectid</emphasis> @@ -461,7 +462,7 @@ <emphasis role="bold">Portal URL</emphasis> </title> <para> - <code>PortalURL</code> play a similar role at the portal level, its main role is to abstract the creation of an URL for a resource managed by the portal. + <code>PortalURL</code> has a similar role at the portal level: its main role is to abstract the creation of a URL for a resource managed by the portal. </para> <programlisting language="Java"> public abstract class PortalURL&lt;R, U extends PortalURL&lt;U&gt;&gt; @@ -485,7 +486,7 @@ </listitem> </itemizedlist> <para> - A portal URL has various methods but certainly the most important method is the <code>toString()</code> method that generates an URL representing that will target the resource associated with the URL. The remaining methods are getter and setter for mutating the URL configuration, those options will affect the URL representation when it is generated. + A portal URL has various methods but certainly the most important method is the <code>toString()</code> method that generates a URL representing that will target the resource associated with the URL. The remaining methods are getter and setter for mutating the URL configuration, those options will affect the URL representation when it is generated. </para> <itemizedlist> <listitem> @@ -519,7 +520,7 @@ RequestContext ctx = RequestContext.getCurrentInstance(); </programlisting> <para> - <code>PortalURL</code> are created via to the <code>createURL</code> method that takes as input a resource type. A resource type is usually a constant and is a type safe object that allow to retrieve <code>PortalURL</code> subclasses: + <code>PortalURL</code> is created with the <code>createURL</code> method that has a resource type as its input parameter. A resource type is usually a constant and a type-safe object that allows to retrieve the <code>PortalURL</code> subclasses: </para> <programlisting language="Java"> RequestContext ctx = RequestContext.getCurrentInstance(); @@ -534,7 +535,7 @@ </programlisting> <note> <para> - The <code>NodeURL.TYPE</code> is actually declared as <code>new ResourceType&lt;NavigationResource, NodeURL&gt;()</code> that can be described as a <emphasis role="bold">type literal</emphasis> object emulated by a Java anonymous inner class. Such literal were introduced by Neil Gafter as Super Type Token and popularized by Google Guice as Type Literal. It&apos;s an interesting way to create a literal representing a kind of Java type. + The <code>NodeURL.TYPE</code> is actually declared as <code>new ResourceType&lt;NavigationResource, NodeURL&gt;()</code> that can be described as a <emphasis role="bold">type literal</emphasis> object emulated by a Java anonymous inner class. Such literals were introduced by Neil Gafter as Super Type Token and popularized by Google Guice as Type Literal. It&apos;s an interesting way to create a literal representing a kind of Java type. </para> </note> </section> @@ -636,7 +637,7 @@ <section id="sect-Reference_Guide-Rendering-Groovy_Templates"> <title>Groovy Templates</title> <para> - Within a Groovy template the mechanism is the same, however a splash of integration has been done to make creation of NodeURL simpler. A closure is bound under the <code>nodeurl</code> name and is available for invocation anytime. It will simply create a NodeURL object and return it: + Within a Groovy template the mechanism is the same, however a splash of integration has been done to make creation of NodeURL simpler. A closure is bound under the <code>nodeurl</code> name and is available for invocation anytime. It will simply create and return a NodeURL object: </para> <programlisting language="Java"> UserNode node = ...; Modified: epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml =================================================================== --- epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml 2012-10-12 15:25:08 UTC (rev 8884) +++ epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml 2012-10-12 15:54:27 UTC (rev 8885) @@ -177,7 +177,7 @@ <term>WEB-INF/gatein-resources.xml</term> <listitem> <para> - For the default portal skin, this file contains definitions for the portal skin, the window decorations that this skin provides and well as defining some JavaScript resources which are not related to the skin. The default portal skin doesn&apos;t directly define portlet skins, these should be provided by the portlets themselves. + For the default portal skin, this file contains definitions for the portal skin, the window decorations that this skin provides as well as defining some JavaScript resources which are not related to the skin. The default portal skin doesn&apos;t directly define portlet skins, these should be provided by the portlets themselves. </para> </listitem> </varlistentry> @@ -185,7 +185,7 @@ <term>WEB-INF/web.xml</term> <listitem> <para> - For the default portal skin, the <filename>web.xml</filename> of the <literal>eXoResources.war</literal> will contains a lot of information which is mostly irrelevant to the portal skinning. The area of interest in this file is the <literal>resourcerequestfilter</literal> and the fact that the <parameter>display-name</parameter> is set. + For the default portal skin, the <filename>web.xml</filename> of the <literal>eXoResources.war</literal> contains a lot of information which is mostly irrelevant to the portal skinning. The area of interest in this file is the <literal>resourcerequestfilter</literal> and the fact that the <parameter>display-name</parameter> is set. </para> </listitem> </varlistentry> @@ -406,7 +406,7 @@ </listitem> </itemizedlist> <para> - This causes JBoss Enterprise Portal Platform to create non-functioning a CSS-link in html-src-code. + This causes JBoss Enterprise Portal Platform to create a non-functioning CSS-link in html-src-code. </para> <procedure> <title>To Resolve This:</title> Modified: epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/configuration.xml =================================================================== --- epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/configuration.xml 2012-10-12 15:25:08 UTC (rev 8884) +++ epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/configuration.xml 2012-10-12 15:54:27 UTC (rev 8885) @@ -624,7 +624,7 @@ The bridge maps a render parameter to a backing bean using settings in your <filename>faces-config.xml</filename> and <filename>portlet.xml</filename>. </para> <para> - A clear and working example can be found in the Seam Booking Demo portlet. <ulink url="http://anonsvn.jboss.org/repos/portletbridge/tags/2.3.0.CP01.EP... + An example can be found in the Seam Booking Demo portlet. <ulink url="http://anonsvn.jboss.org/repos/portletbridge/tags/2.3.1.GA.EPP5... </para> <para> You must define the following <emphasis>init params</emphasis> in your <filename>portlet.xml</filename>. @@ -652,7 +652,7 @@ We have setup a few examples to show you how to use <literal>EL</literal> and a simple bean that will allow you to use the portlet resource serving mechanism within a JSF portlet. </para> <para> - In <ulink url="http://anonsvn.jboss.org/repos/portletbridge/tags/2.3.0.CP01.EP...;, you can see a very simple implementation of a Map object that uses the bridge to get and encode a resource URL served from the portlet application. + In <ulink url="http://anonsvn.jboss.org/repos/portletbridge/tags/2.3.1.GA.EPP5...;, you can see a very simple implementation of a Map object that uses the bridge to get and encode a resource URL served from the portlet application. </para> <para> So, when you have the normal &quot;<filename>/images</filename>&quot;, &quot;<filename>/styles</filename>&quot; and other resource folders in your web application, you can use the following <literal>EL</literal> expression to serve them in your JSF application. Modified: epp/docs/branches/5.2/Reference_Guide/en-US/modules/WSRP.xml =================================================================== --- epp/docs/branches/5.2/Reference_Guide/en-US/modules/WSRP.xml 2012-10-12 15:25:08 UTC (rev 8884) +++ epp/docs/branches/5.2/Reference_Guide/en-US/modules/WSRP.xml 2012-10-12 15:54:27 UTC (rev 8885) @@ -113,7 +113,7 @@ <listitem> <para> The <filename>extension-config-&VZ;.jar</filename>, which contains the configuration file - needed by the GateIn extension mechanism to properly register this EAR as an extension. + needed by the portal extension mechanism to properly register this EAR as an extension. </para> </listitem> <listitem> @@ -154,18 +154,11 @@ <section id="wsrp-ports"> <title>Considerations to use WSRP when running JBoss Enterprise Portal Platform on a non-default port or hostname</title> <para> - JBoss WS (the web service stack that JBoss Enterprise Portal Platform uses) should take care of the details of updating the - port and host name used in WSDL. See the - <ulink url="http://community.jboss.org/wiki/JBossWS-UserGuide#Configuration... WS user guide on that subject </ulink> - for more details. + JBoss WS, the web service stack that JBoss Enterprise Portal Platform uses, is used to update the + port and host name used in WSDL. Refer to <citetitle>JBoss WS user guide</citetitle> for more details. </para> <para> - Of course, if you have modified the host name and port on which your server runs, you will - need to - update the configuration for the consumer used to consume JBoss Enterprise Portal Platform&apos;s &apos;self&apos; producer. Please refer to - the - <xref linkend="consumer_configuration"/> - to learn how to do so. + If you have modified the host name and port on which your server runs, make sure that you update the configuration for the consumer used to consume JBoss Enterprise Portal Platform&apos;s &apos;self&apos; producer (refer to <xref linkend="consumer_configuration"/>). </para> </section> </section>