Author: chris.laprun(a)jboss.com Date: 2007-10-12 20:08:20 -0400 (Fri, 12 Oct 2007) New Revision: 8625 Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/urls.xml docs/trunk/referenceGuide/en/modules/urls.xml Log: - Minor content improvements. Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/urls.xml =================================================================== --- docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/urls.xml 2007-10-12 23:40:19 UTC (rev 8624) +++ docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/urls.xml 2007-10-13 00:08:20 UTC (rev 8625) @@ -31,71 +31,74 @@ <sect1> <title>Accessing a portal</title> <para>Each portal container can contains multiple portals, also there is one special portal - which is the default portal, i.e the one used when no portal is specified in particular. - <itemizedlist> The following examples show you how the selection is done. - <listitem>"/", will point to the default page of the default portal.</listitem> - <listitem>"/portal/portalname/" will point to the default page of the portal - <literal>portalname</literal> - </listitem> - </itemizedlist> + which is the default portal, i.e the one used when no portal is specified in particular. + <itemizedlist> The following examples show you how the selection is done. + <listitem>"/portal", will point to the default page of the default portal.</listitem> + <listitem>"/portal/portalname/" will point to the default page of the portal + <literal>portalname</literal> + </listitem> + </itemizedlist> </para> </sect1> <sect1> <title>Accessing a page</title> <para>It is possible to have multiple pages per portal. As for portal there is a default - page for a given portal. Once the portal has been selected, then a page must be used and - all the windows present in that page will be rendered. The page selection mechanism is - the following. <itemizedlist> - <listitem>"/portal/default/pageName" will render the <literal>pageName</literal> - page.</listitem> - </itemizedlist> + page for a given portal. Once the portal has been selected, then a page must be used and + all the windows present in that page will be rendered. The page selection mechanism is + the following. + <itemizedlist> + <listitem>"/portal/default/pageName" will render the <literal>pageName</literal> + page.</listitem> + </itemizedlist> </para> </sect1> <sect1> <title>Accessing CMS Content</title> <para>The CMSPortlet delivers content transparently, without modifying the url displayed. - However, if you wish to deliver binary content (gif, jpeg, pdf, zip, etc...), it is - desirable to display this content outside of the confines of the portal.</para> - <itemizedlist> - <listitem> - <literal>"/content/default/images/jboss_logo.gif"</literal> will display the - <literal>jboss_logo.gif</literal> outside of the portal. This is accomplished as - the portal interprets any path beginning with <literal>/content</literal> as a - request for CMS content. As long as the mime-type is not text/html or text/text, it - will be rendered independant of the portal. </listitem> - </itemizedlist> + However, if you wish to deliver binary content (gif, jpeg, pdf, zip, etc...), it is + desirable to display this content outside of the confines of the portal. + <itemizedlist> + <listitem> + <literal>"/content/default/images/jboss_logo.gif"</literal> will display the + <literal>jboss_logo.gif</literal> outside of the portal. This is accomplished as + the portal interprets any path beginning with <literal>/content</literal> as a + request for CMS content. As long as the mime-type is not <literal>text/html</literal> + or <literal>text/text</literal>, it will be rendered independently of the portal. + </listitem> + </itemizedlist> + </para> </sect1> -<!-- - <sect1> - <title>Advanced portal urls</title> - <para>JBoss Portal can consume and produce URLs in a very flexible manner. Consuming means - that an URL is accepted by the portal, translated into some action and send a response to the - browser. Producing means to create an URL for a particular action when the portal needs one. - This part is an advanced topic explaining the internal mechanisms developped in JBoss Portal to - produce and consumer URLs. It should be readen with care as it exposes internals of JBoss Portal - that may change in later releases of the product.</para> - <para>JBoss Portal url handling mechanism is based on several design patterns.</para> - <sect2> - <title>Portal Commands</title> - <para></para> - </sect2> - <sect2> - <title>Portal urls</title> - <para>At runtime portal commands are converted back and forth into portal urls. Creation - of urls and decoding of urls is now known at compile time, otherwise that would lead - to a very inflexible portal since changing the behavior would imply to update the source - code and recompile the portal, that would not be an acceptable solution. There is - a well known design pattern which provides an elegant and powerful solution to this problem and - is called Chain of Responsibility.</para> - <para>Portal commands have a state which parameterizes them. For instance there is a command - called <emphasis>ViewPageCommand</emphasis> which displays a portal page in the browser. The state - of that command consist in the id of the page. There is a bidirectionnal mapping between portal urls - and portal commands. Portal commands are created from URL using a service called <emphasis>CommandFactory</emphasis>, - which takes a request object and provides a portal command. Conversely, portal urls are created from - portal commands using a service called <emphasis>URLFactory</emphasis>.</para> - <para>The task of decoding urls is performed by a set of command factories which are wired - together in the configuration file. We can dist</para> - </sect2> - </sect1> ---> + <!-- + <sect1> + <title>Advanced portal urls</title> + <para>JBoss Portal can consume and produce URLs in a very flexible manner. Consuming means + that an URL is accepted by the portal, translated into some action and send a response to the + browser. Producing means to create an URL for a particular action when the portal needs one. + This part is an advanced topic explaining the internal mechanisms developped in JBoss Portal to + produce and consumer URLs. It should be readen with care as it exposes internals of JBoss Portal + that may change in later releases of the product.</para> + <para>JBoss Portal url handling mechanism is based on several design patterns.</para> + <sect2> + <title>Portal Commands</title> + <para></para> + </sect2> + <sect2> + <title>Portal urls</title> + <para>At runtime portal commands are converted back and forth into portal urls. Creation + of urls and decoding of urls is now known at compile time, otherwise that would lead + to a very inflexible portal since changing the behavior would imply to update the source + code and recompile the portal, that would not be an acceptable solution. There is + a well known design pattern which provides an elegant and powerful solution to this problem and + is called Chain of Responsibility.</para> + <para>Portal commands have a state which parameterizes them. For instance there is a command + called <emphasis>ViewPageCommand</emphasis> which displays a portal page in the browser. The state + of that command consist in the id of the page. There is a bidirectionnal mapping between portal urls + and portal commands. Portal commands are created from URL using a service called <emphasis>CommandFactory</emphasis>, + which takes a request object and provides a portal command. Conversely, portal urls are created from + portal commands using a service called <emphasis>URLFactory</emphasis>.</para> + <para>The task of decoding urls is performed by a set of command factories which are wired + together in the configuration file. We can dist</para> + </sect2> + </sect1> + --> </chapter> Modified: docs/trunk/referenceGuide/en/modules/urls.xml =================================================================== --- docs/trunk/referenceGuide/en/modules/urls.xml 2007-10-12 23:40:19 UTC (rev 8624) +++ docs/trunk/referenceGuide/en/modules/urls.xml 2007-10-13 00:08:20 UTC (rev 8625) @@ -31,71 +31,74 @@ <sect1> <title>Accessing a portal</title> <para>Each portal container can contains multiple portals, also there is one special portal - which is the default portal, i.e the one used when no portal is specified in particular. - <itemizedlist> The following examples show you how the selection is done. - <listitem>"/", will point to the default page of the default portal.</listitem> - <listitem>"/portal/portalname/" will point to the default page of the portal - <literal>portalname</literal> - </listitem> - </itemizedlist> + which is the default portal, i.e the one used when no portal is specified in particular. + <itemizedlist> The following examples show you how the selection is done. + <listitem>"/portal", will point to the default page of the default portal.</listitem> + <listitem>"/portal/portalname/" will point to the default page of the portal + <literal>portalname</literal> + </listitem> + </itemizedlist> </para> </sect1> <sect1> <title>Accessing a page</title> <para>It is possible to have multiple pages per portal. As for portal there is a default - page for a given portal. Once the portal has been selected, then a page must be used and - all the windows present in that page will be rendered. The page selection mechanism is - the following. <itemizedlist> - <listitem>"/portal/default/pageName" will render the <literal>pageName</literal> - page.</listitem> - </itemizedlist> + page for a given portal. Once the portal has been selected, then a page must be used and + all the windows present in that page will be rendered. The page selection mechanism is + the following. + <itemizedlist> + <listitem>"/portal/default/pageName" will render the <literal>pageName</literal> + page.</listitem> + </itemizedlist> </para> </sect1> <sect1> <title>Accessing CMS Content</title> <para>The CMSPortlet delivers content transparently, without modifying the url displayed. - However, if you wish to deliver binary content (gif, jpeg, pdf, zip, etc...), it is - desirable to display this content outside of the confines of the portal.</para> - <itemizedlist> - <listitem> - <literal>"/content/default/images/jboss_logo.gif"</literal> will display the - <literal>jboss_logo.gif</literal> outside of the portal. This is accomplished as - the portal interprets any path beginning with <literal>/content</literal> as a - request for CMS content. As long as the mime-type is not text/html or text/text, it - will be rendered independant of the portal. </listitem> - </itemizedlist> + However, if you wish to deliver binary content (gif, jpeg, pdf, zip, etc...), it is + desirable to display this content outside of the confines of the portal. + <itemizedlist> + <listitem> + <literal>"/content/default/images/jboss_logo.gif"</literal> will display the + <literal>jboss_logo.gif</literal> outside of the portal. This is accomplished as + the portal interprets any path beginning with <literal>/content</literal> as a + request for CMS content. As long as the mime-type is not <literal>text/html</literal> + or <literal>text/text</literal>, it will be rendered independently of the portal. + </listitem> + </itemizedlist> + </para> </sect1> -<!-- - <sect1> - <title>Advanced portal urls</title> - <para>JBoss Portal can consume and produce URLs in a very flexible manner. Consuming means - that an URL is accepted by the portal, translated into some action and send a response to the - browser. Producing means to create an URL for a particular action when the portal needs one. - This part is an advanced topic explaining the internal mechanisms developped in JBoss Portal to - produce and consumer URLs. It should be readen with care as it exposes internals of JBoss Portal - that may change in later releases of the product.</para> - <para>JBoss Portal url handling mechanism is based on several design patterns.</para> - <sect2> - <title>Portal Commands</title> - <para></para> - </sect2> - <sect2> - <title>Portal urls</title> - <para>At runtime portal commands are converted back and forth into portal urls. Creation - of urls and decoding of urls is now known at compile time, otherwise that would lead - to a very inflexible portal since changing the behavior would imply to update the source - code and recompile the portal, that would not be an acceptable solution. There is - a well known design pattern which provides an elegant and powerful solution to this problem and - is called Chain of Responsibility.</para> - <para>Portal commands have a state which parameterizes them. For instance there is a command - called <emphasis>ViewPageCommand</emphasis> which displays a portal page in the browser. The state - of that command consist in the id of the page. There is a bidirectionnal mapping between portal urls - and portal commands. Portal commands are created from URL using a service called <emphasis>CommandFactory</emphasis>, - which takes a request object and provides a portal command. Conversely, portal urls are created from - portal commands using a service called <emphasis>URLFactory</emphasis>.</para> - <para>The task of decoding urls is performed by a set of command factories which are wired - together in the configuration file. We can dist</para> - </sect2> - </sect1> ---> + <!-- + <sect1> + <title>Advanced portal urls</title> + <para>JBoss Portal can consume and produce URLs in a very flexible manner. Consuming means + that an URL is accepted by the portal, translated into some action and send a response to the + browser. Producing means to create an URL for a particular action when the portal needs one. + This part is an advanced topic explaining the internal mechanisms developped in JBoss Portal to + produce and consumer URLs. It should be readen with care as it exposes internals of JBoss Portal + that may change in later releases of the product.</para> + <para>JBoss Portal url handling mechanism is based on several design patterns.</para> + <sect2> + <title>Portal Commands</title> + <para></para> + </sect2> + <sect2> + <title>Portal urls</title> + <para>At runtime portal commands are converted back and forth into portal urls. Creation + of urls and decoding of urls is now known at compile time, otherwise that would lead + to a very inflexible portal since changing the behavior would imply to update the source + code and recompile the portal, that would not be an acceptable solution. There is + a well known design pattern which provides an elegant and powerful solution to this problem and + is called Chain of Responsibility.</para> + <para>Portal commands have a state which parameterizes them. For instance there is a command + called <emphasis>ViewPageCommand</emphasis> which displays a portal page in the browser. The state + of that command consist in the id of the page. There is a bidirectionnal mapping between portal urls + and portal commands. Portal commands are created from URL using a service called <emphasis>CommandFactory</emphasis>, + which takes a request object and provides a portal command. Conversely, portal urls are created from + portal commands using a service called <emphasis>URLFactory</emphasis>.</para> + <para>The task of decoding urls is performed by a set of command factories which are wired + together in the configuration file. We can dist</para> + </sect2> + </sect1> + --> </chapter>