Author: roy.russo(a)jboss.com Date: 2007-01-31 10:36:53 -0500 (Wed, 31 Jan 2007) New Revision: 6132 Added: docs/trunk/userGuide/en/images/intro/dashboard_add.gif Modified: docs/trunk/referenceGuide/en/master.xml docs/trunk/referenceGuide/en/modules/migration.xml docs/trunk/referenceGuide/en/modules/themeandlayouts.xml docs/trunk/userGuide/en/master.xml docs/trunk/userGuide/en/modules/intro.xml Log: JBPORTAL-1031 - installer update JBPORTAL-1197 - page cloning JBPORTAL-1210 - remove layout strat Modified: docs/trunk/referenceGuide/en/master.xml =================================================================== --- docs/trunk/referenceGuide/en/master.xml 2007-01-30 23:55:58 UTC (rev 6131) +++ docs/trunk/referenceGuide/en/master.xml 2007-01-31 15:36:53 UTC (rev 6132) @@ -26,10 +26,10 @@ ]> <book lang="en"> <bookinfo> - <title>JBoss Portal 2.6Alpha</title> + <title>JBoss Portal 2.6Alpha2</title> <subtitle>Reference Guide</subtitle> - <releaseinfo>Release 2.6Alpha "Ninja"</releaseinfo> - <releaseinfo>October 2006</releaseinfo> + <releaseinfo>Release 2.6Alpha2 "Ninja"</releaseinfo> + <releaseinfo>February 2007</releaseinfo> <author> <firstname>Thomas</firstname> <surname>Heute</surname> Modified: docs/trunk/referenceGuide/en/modules/migration.xml =================================================================== --- docs/trunk/referenceGuide/en/modules/migration.xml 2007-01-30 23:55:58 UTC (rev 6131) +++ docs/trunk/referenceGuide/en/modules/migration.xml 2007-01-31 15:36:53 UTC (rev 6132) @@ -11,7 +11,11 @@ <email>boleslaw.dawidowicz at jboss dot com</email> </author> </chapterinfo> - <title>Upgrading 2.2 - 2.4</title> + <title>Upgrading 2.4 - 2.6</title> + <warning> + This section to be updated soon with 2.4 to 2.6 migration instructions, using the Migration Application. + </warning> +<!-- <para>This chapter addresses migration issues from version 2.2 to 2.4 of JBoss Portal.</para> <sect1 id="migrating_database"> <title>Migrating the Database</title> @@ -577,5 +581,6 @@ </itemizedlist> </sect2> </sect1> +--> </chapter> Modified: docs/trunk/referenceGuide/en/modules/themeandlayouts.xml =================================================================== --- docs/trunk/referenceGuide/en/modules/themeandlayouts.xml 2007-01-30 23:55:58 UTC (rev 6131) +++ docs/trunk/referenceGuide/en/modules/themeandlayouts.xml 2007-01-31 15:36:53 UTC (rev 6132) @@ -72,21 +72,23 @@ themes, we strongly believe that the last approach is superior, and allows for far more flexibility, and clearer separation of duties between portal developers and web designers. </para> - <para>Portal layouts also have the concept of a layout strategy. The layout strategy is a - pluggable API, and lets the layout developer have a last say about the content to be - rendered. The strategy is called right after the portal has determined what needs to be - rendered as part of the current request. So the strategy is invoked right between the point - where the portal knows what needs to be done, and before the actual work is initiated. The - strategy gets all the details about what is going to happen, and it can take measures to - influence those details. - <itemizedlist> - <para>Some simple examples of those measures are:</para> - <listitem>ommit one of the portlets from being rendered</listitem> - <listitem>change the portlet mode or window state of a portlet before it gets rendered</listitem> - <listitem>change the layout to be used for this request</listitem> - <listitem>...and many more</listitem> - </itemizedlist> - </para> + <!-- + <para>Portal layouts also have the concept of a layout strategy. The layout strategy is a + pluggable API, and lets the layout developer have a last say about the content to be + rendered. The strategy is called right after the portal has determined what needs to be + rendered as part of the current request. So the strategy is invoked right between the point + where the portal knows what needs to be done, and before the actual work is initiated. The + strategy gets all the details about what is going to happen, and it can take measures to + influence those details. + <itemizedlist> + <para>Some simple examples of those measures are:</para> + <listitem>ommit one of the portlets from being rendered</listitem> + <listitem>change the portlet mode or window state of a portlet before it gets rendered</listitem> + <listitem>change the layout to be used for this request</listitem> + <listitem>...and many more</listitem> + </itemizedlist> + </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 that together decide about the look and feel of the portal page. The theme can take a wide @@ -196,21 +198,23 @@ even rebuild the core portal itself. </para> </sect2> + <!-- + <sect2> + <title>How to connect a Layout to a Layout Strategy</title> + <para>As you might have noticed already, a layout definition consists of a name and one or + more uri elements. We have already seen the function of the name element. Now let's take + a closer look at the uri element. In the example above, the phalanx layout defined one + uri element only, the industrial layout defines two. What you can see in the industrial + layout is the option of defining different uri's for different states. In this example , + we configured the layout to use a different JSP if the layout state is maximized. If no + such separation is made in the layout descriptor, then the portal will always use the + same JSP for this layout. Note that the 'state' attribute value works together with the + state that was set by the layout strategy. Please refere to the section about the layout + strategy for more details. + </para> + </sect2> + --> <sect2> - <title>How to connect a Layout to a Layout Strategy</title> - <para>As you might have noticed already, a layout definition consists of a name and one or - more uri elements. We have already seen the function of the name element. Now let's take - a closer look at the uri element. In the example above, the phalanx layout defined one - uri element only, the industrial layout defines two. What you can see in the industrial - layout is the option of defining different uri's for different states. In this example , - we configured the layout to use a different JSP if the layout state is maximized. If no - such separation is made in the layout descriptor, then the portal will always use the - same JSP for this layout. Note that the 'state' attribute value works together with the - state that was set by the layout strategy. Please refere to the section about the layout - strategy for more details. - </para> - </sect2> - <sect2> <title>Layout JSP-tags</title> <para>The portal comes with a set of JSP tags that allow the layout developer faster development. @@ -305,148 +309,152 @@ </para> </sect2> </sect1> - <sect1> - <title>Layout Strategy</title> - <sect2> - <title>What is a Layout Strategy</title> - <para>The layout strategy is a pluggable API that allows the layout developer to influence - the content of the page that is about to be rendered. Based on the current request URL, - the portal determined the portal and page that needs to be rendered. The page contains a - list of portlets, and those portlets are in a particular navigational state. The - navigational state consists of the portlet mode and the window state of the portlet. - This information, togeher with the determined layout, the region and order assignments - of each portlet, the allowed window states and portlet modes for both, the portal and - the individual portlets, is passed to the layout strategy before the actual rendering is - invoked. The layout strategy can check what is about to be rendered, and take action in - a limited way to influence the content that is about to be rendered. - </para> - </sect2> - <sect2> - <title>How can I use a Layout Strategy</title> - <sect3> - <title>Define a Strategy</title> - <para>A layout strategy is defined in the strategy descriptor. The descriptor is named - portal-strategies.xml, and is located in the WEB-INF/layout folder of any web - application deployed to the server. Here is an example of such a descriptor: - <programlisting> - <![CDATA[<portal-strategies> - <set name="default"> - <strategy content-type="text/html"> - <implementation>org.jboss.portal.theme.impl.strategy.DefaultStrategyImpl</implementation> - </strategy> - </set> - <set name="maximizedRegion"> - <strategy content-type="text/html"> - <implementation>org.jboss.portal.theme.impl.strategy.MaximizingStrategyImpl</implementation> - </strategy> - </set> - </portal-strategies> - ]]></programlisting> - Layout strategies are defined as sets. A set consists of one or - more strategy definitions, separated by content type they are assigned for. The idea - behind this is to allow the layout developer to apply different strategies based on - requested content type. Each set has a name that is unique in the application context - it is deployed in. The strategy can be refered to by this name. As a result of that - it is considered a named layout strategy in contrast to an anonymous strategy as - described below. + <!-- +<sect1> +<title>Layout Strategy</title> +<sect2> +<title>What is a Layout Strategy</title> +<para>The layout strategy is a pluggable API that allows the layout developer to influence +the content of the page that is about to be rendered. Based on the current request URL, +the portal determined the portal and page that needs to be rendered. The page contains a +list of portlets, and those portlets are in a particular navigational state. The +navigational state consists of the portlet mode and the window state of the portlet. +This information, togeher with the determined layout, the region and order assignments +of each portlet, the allowed window states and portlet modes for both, the portal and +the individual portlets, is passed to the layout strategy before the actual rendering is +invoked. The layout strategy can check what is about to be rendered, and take action in +a limited way to influence the content that is about to be rendered. +</para> +</sect2> +<sect2> +<title>How can I use a Layout Strategy</title> +<sect3> +<title>Define a Strategy</title> +<para>A layout strategy is defined in the strategy descriptor. The descriptor is named + portal-strategies.xml, and is located in the WEB-INF/layout folder of any web + application deployed to the server. Here is an example of such a descriptor: + <programlisting> + <![CDATA[<portal-strategies> + <set name="default"> + <strategy content-type="text/html"> + <implementation>org.jboss.portal.theme.impl.strategy.DefaultStrategyImpl</implementation> + </strategy> + </set> + <set name="maximizedRegion"> + <strategy content-type="text/html"> + <implementation>org.jboss.portal.theme.impl.strategy.MaximizingStrategyImpl</implementation> + </strategy> + </set> + </portal-strategies> + ]]></programlisting> + Layout strategies are defined as sets. A set consists of one or + more strategy definitions, separated by content type they are assigned for. The idea + behind this is to allow the layout developer to apply different strategies based on + requested content type. Each set has a name that is unique in the application context + it is deployed in. The strategy can be refered to by this name. As a result of that + it is considered a named layout strategy in contrast to an anonymous strategy as + described below. +</para> +</sect3> +<sect3> +<title>Specify the Strategy to use</title> +<para>The strategy that will be used for a portal request is defined as a property of + the current layout, the requested portal, or the requested page. If the layout + defines a strategy to use it will overwrite all other assignments. If there is no + particular strategy defined for the layout, then the page property will overwrite the + portal property. If no strategy can be determined, then a last attempt will be made + to use the strategy with the name 'default'. If no strategy can be determined at all, + the request will proceed normally without invoking any strategy. Here is an example + layout descriptor that defines a strategy for the layouts defined: + <programlisting> + <![CDATA[ + <layouts> + <strategy content-type="text/html"> + <implementation>com.novell.portal.strategy.MaximizingStrategy</implementation> + </strategy> + + <layout> + <name>generic</name> + <uri>/generic/index.jsp</uri> + <uri state="maximized">/generic/maximized.jsp</uri> + </layout> + </layouts> + ]]></programlisting> + In this case the strategy is anonymous and directly assigned to + the generic layout. The strategy cannot be discovered independently from the generic + layout. Here is an example portal descriptor that points to a strategy for the + portal, and for a particular page: + <programlisting> + <![CDATA[ + <portal> + <portal-name>default</portal-name> + <properties> + <property> + <name>layout.strategyId</name> + <value>default</value> + </property> + </properties> + <pages> + <default-page>theme test</default-page> + <page> + <page-name>theme test</page-name> + <properties> + --> + <!-- set a difference layout strategy for this page --> + <!-- + <property> + <name>layout.strategyId</name> + <value>maximizedRegion</value> + </property> + </properties> + <window> + <window-name>CatalogPortletWindow</window-name> + <instance-ref>CatalogPortletInstance</instance-ref> + <region>left</region> + <height>0</height> + </window> + </page> + </pages> + </portal> + ]]></programlisting> + As you can see, analogous to how layouts are refered to, the + strategy name is the linking element between the portal descriptor and the layout + strategy descriptor. The content type is determined at runtime, and serves as a + secondary query parameter to get the correct strategy for this content type out of + the set that matches the name provided in the portal descriptor. + </para> + </sect3> + </sect2> + <sect2> + <title>Linking the Strategy and the Layout</title> + <para>As mentioned above, the layout descriptor can link a strategy directly to the + layout. This will overwrite all other defined strategies for the portal or the page, for + any page that uses this layout. </para> - </sect3> - <sect3> - <title>Specify the Strategy to use</title> - <para>The strategy that will be used for a portal request is defined as a property of - the current layout, the requested portal, or the requested page. If the layout - defines a strategy to use it will overwrite all other assignments. If there is no - particular strategy defined for the layout, then the page property will overwrite the - portal property. If no strategy can be determined, then a last attempt will be made - to use the strategy with the name 'default'. If no strategy can be determined at all, - the request will proceed normally without invoking any strategy. Here is an example - layout descriptor that defines a strategy for the layouts defined: - <programlisting> - <![CDATA[ + <para>The layout strategy can set a state to return to the portal as a result of the + strategy evaluation. This state will be matched with the state attribute of the uri + element of the layout. If there is a match, then the uri that matches this state will be + used as the layout for the current request. So, if the strategy sets a state of + 'maximized' , the portal will try to use the layout resource that is pointed to for that + particular state in the currently selected layout. As you might remember from the + previous layout section, a layout can point to another JSP or Servlet based on the state + attribute of the uri element, like so: + <programlisting><![CDATA[ <layouts> - <strategy content-type="text/html"> - <implementation>com.novell.portal.strategy.MaximizingStrategy</implementation> - </strategy> - <layout> - <name>generic</name> - <uri>/generic/index.jsp</uri> - <uri state="maximized">/generic/maximized.jsp</uri> + <name>industrial</name> + <uri>/industrial/index.jsp</uri> + <uri state="maximized">/industrial/maximized.jsp</uri> </layout> - </layouts> - ]]></programlisting> - In this case the strategy is anonymous and directly assigned to - the generic layout. The strategy cannot be discovered independently from the generic - layout. Here is an example portal descriptor that points to a strategy for the - portal, and for a particular page: - <programlisting> - <![CDATA[ - <portal> - <portal-name>default</portal-name> - <properties> - <property> - <name>layout.strategyId</name> - <value>default</value> - </property> - </properties> - <pages> - <default-page>theme test</default-page> - <page> - <page-name>theme test</page-name> - <properties> - <!-- set a difference layout strategy for this page --> - <property> - <name>layout.strategyId</name> - <value>maximizedRegion</value> - </property> - </properties> - <window> - <window-name>CatalogPortletWindow</window-name> - <instance-ref>CatalogPortletInstance</instance-ref> - <region>left</region> - <height>0</height> - </window> - </page> - </pages> - </portal> - ]]></programlisting> - As you can see, analogous to how layouts are refered to, the - strategy name is the linking element between the portal descriptor and the layout - strategy descriptor. The content type is determined at runtime, and serves as a - secondary query parameter to get the correct strategy for this content type out of - the set that matches the name provided in the portal descriptor. + </layouts>]]></programlisting> + In this case all reuquests that don't return a state + 'maximized' from the evaluation of the strategy will use the /industrial/index.jsp as + the layout. However, if the evaluation of the strategy returns a state of 'maximized' + then the request will use /industrial/maximized.jsp as the layout. </para> - </sect3> - </sect2> - <sect2> - <title>Linking the Strategy and the Layout</title> - <para>As mentioned above, the layout descriptor can link a strategy directly to the - layout. This will overwrite all other defined strategies for the portal or the page, for - any page that uses this layout. - </para> - <para>The layout strategy can set a state to return to the portal as a result of the - strategy evaluation. This state will be matched with the state attribute of the uri - element of the layout. If there is a match, then the uri that matches this state will be - used as the layout for the current request. So, if the strategy sets a state of - 'maximized' , the portal will try to use the layout resource that is pointed to for that - particular state in the currently selected layout. As you might remember from the - previous layout section, a layout can point to another JSP or Servlet based on the state - attribute of the uri element, like so: - <programlisting><![CDATA[ - <layouts> - <layout> - <name>industrial</name> - <uri>/industrial/index.jsp</uri> - <uri state="maximized">/industrial/maximized.jsp</uri> - </layout> - </layouts>]]></programlisting> - In this case all reuquests that don't return a state - 'maximized' from the evaluation of the strategy will use the /industrial/index.jsp as - the layout. However, if the evaluation of the strategy returns a state of 'maximized' - then the request will use /industrial/maximized.jsp as the layout. - </para> - </sect2> - </sect1> + </sect2> + </sect1> + --> <sect1> <title>RenderSets</title> <sect2> Added: docs/trunk/userGuide/en/images/intro/dashboard_add.gif =================================================================== (Binary files differ) Property changes on: docs/trunk/userGuide/en/images/intro/dashboard_add.gif ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Modified: docs/trunk/userGuide/en/master.xml =================================================================== --- docs/trunk/userGuide/en/master.xml 2007-01-30 23:55:58 UTC (rev 6131) +++ docs/trunk/userGuide/en/master.xml 2007-01-31 15:36:53 UTC (rev 6132) @@ -13,10 +13,10 @@ ]> <book lang="en"> <bookinfo> - <title>JBoss Portal 2.6Alpha</title> + <title>JBoss Portal 2.6Alpha2</title> <subtitle>User Guide</subtitle> - <releaseinfo>Release 2.6Alpha "Ninja"</releaseinfo> - <releaseinfo>October 2006</releaseinfo> + <releaseinfo>Release 2.6Alpha2 "Ninja"</releaseinfo> + <releaseinfo>February 2007</releaseinfo> <author> <firstname>Roy</firstname> <surname>Russo</surname> Modified: docs/trunk/userGuide/en/modules/intro.xml =================================================================== --- docs/trunk/userGuide/en/modules/intro.xml 2007-01-30 23:55:58 UTC (rev 6131) +++ docs/trunk/userGuide/en/modules/intro.xml 2007-01-31 15:36:53 UTC (rev 6132) @@ -544,6 +544,17 @@ While navigating any of the dashboard pages, a user will be able to drag and drop portlet windows to any location, if the administrator allows this functionality. Changes made in this fashion will be persisted. </para> + <para> + <mediaobject> + <imageobject> + <imagedata fileref="images/intro/dashboard_add.gif" format="gif" align="center" + valign="middle"/> + </imageobject> + </mediaobject> + You are also able to add(clone) shared pages to your personal dashboard, by selecting the + <emphasis>Add to Dashboard</emphasis> + link. This will clone the page and add it to your personal dashboard as a page with the same name. + </para> <sect2 id="dashboard_configure"> <title>Configuring your personal dashboard</title> <para>