From portal-commits at lists.jboss.org Wed Jan 31 10:36:54 2007
Content-Type: multipart/mixed; boundary="===============1289461006903912294=="
MIME-Version: 1.0
From: portal-commits at lists.jboss.org
To: portal-commits at lists.jboss.org
Subject: [portal-commits] JBoss Portal SVN: r6132 - in docs/trunk:
 referenceGuide/en/modules and 3 other directories.
Date: Wed, 31 Jan 2007 10:36:53 -0500
Message-ID: <E1HCHW1-0003dl-Vd@committer01.frg.pub.inap.atl.jboss.com>

--===============1289461006903912294==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- docs/trunk/referenceGuide/en/master.xml	2007-01-30 23:55:58 UTC (rev 61=
31)
+++ docs/trunk/referenceGuide/en/master.xml	2007-01-31 15:36:53 UTC (rev 61=
32)
@@ -26,10 +26,10 @@
       ]>
 <book lang=3D"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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- 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 instructio=
ns, using the Migration Application.
+   </warning>
+<!--
    <para>This chapter addresses migration issues from version 2.2 to 2.4 o=
f JBoss Portal.</para>
    <sect1 id=3D"migrating_database">
       <title>Migrating the Database</title>
@@ -577,5 +581,6 @@
          </itemizedlist>
       </sect2>
    </sect1>
+-->
 =

 </chapter>

Modified: docs/trunk/referenceGuide/en/modules/themeandlayouts.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- 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, a=
nd allows for far more
          flexibility, and clearer separation of duties between portal deve=
lopers 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 abou=
t the content to be
-         rendered. The strategy is called right after the portal has deter=
mined what needs to be
-         rendered as part of the current request. So the strategy is invok=
ed right between the point
-         where the portal knows what needs to be done, and before the actu=
al 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</listi=
tem>
-            <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</listi=
tem>
-            <listitem>...and many more</listitem>
-         </itemizedlist>
-      </para>
+      <!--
+            <para>Portal layouts also have the concept of a layout strateg=
y. The layout strategy is a
+               pluggable API, and lets the layout developer have a last sa=
y 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 th=
e 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 p=
ortlet 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 por=
tal 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 definitio=
n 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. Wha=
t you can see in the industrial
+                  layout is the option of defining different uri's for dif=
ferent states. In this example ,
+                  we configured the layout to use a different JSP if the l=
ayout state is maximized. If no
+                  such separation is made in the layout descriptor, then t=
he portal will always use the
+                  same JSP for this layout. Note that the 'state' attribut=
e 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 cons=
ists of a name and one or
-            more uri elements. We have already seen the function of the na=
me element. Now let's take
-            a closer look at the uri element. In the example above, the ph=
alanx 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 por=
tal will always use the
-            same JSP for this layout. Note that the 'state' attribute valu=
e works together with the
-            state that was set by the layout strategy. Please refere to th=
e 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 layo=
ut 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 layo=
ut 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 ren=
dered. The page contains a
-            list of portlets, and those portlets are in a particular navig=
ational state. The
-            navigational state consists of the portlet mode and the window=
 state of the portlet.
-            This information, togeher with the determined layout, the regi=
on and order assignments
-            of each portlet, the allowed window states and portlet modes f=
or both, the portal and
-            the individual portlets, is passed to the layout strategy befo=
re the actual rendering is
-            invoked. The layout strategy can check what is about to be ren=
dered, and take action in
-            a limited way to influence the content that is about to be ren=
dered.
-         </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 s=
uch a descriptor:
-               <programlisting>
-                  <![CDATA[<portal-strategies>
-               <set name=3D"default">
-               <strategy content-type=3D"text/html">
-               <implementation>org.jboss.portal.theme.impl.strategy.Defaul=
tStrategyImpl</implementation>
-               </strategy>
-               </set>
-               <set name=3D"maximizedRegion">
-               <strategy content-type=3D"text/html">
-               <implementation>org.jboss.portal.theme.impl.strategy.Maximi=
zingStrategyImpl</implementation>
-               </strategy>
-               </set>
-               </portal-strategies>
-               ]]></programlisting>
-               Layout strategies are defined as sets. A set consists of on=
e or
-               more strategy definitions, separated by content type they a=
re assigned for. The idea
-               behind this is to allow the layout developer to apply diffe=
rent 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 n=
ame. 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 develo=
per 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 p=
age contains a
+list of portlets, and those portlets are in a particular navigational stat=
e. The
+navigational state consists of the portlet mode and the window state of th=
e 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 actua=
l rendering is
+invoked. The layout strategy can check what is about to be rendered, and t=
ake 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 descrip=
tor is named
+   portal-strategies.xml, and is located in the WEB-INF/layout folder of a=
ny web
+   application deployed to the server. Here is an example of such a descri=
ptor:
+   <programlisting>
+      <![CDATA[<portal-strategies>
+   <set name=3D"default">
+   <strategy content-type=3D"text/html">
+   <implementation>org.jboss.portal.theme.impl.strategy.DefaultStrategyImp=
l</implementation>
+   </strategy>
+   </set>
+   <set name=3D"maximizedRegion">
+   <strategy content-type=3D"text/html">
+   <implementation>org.jboss.portal.theme.impl.strategy.MaximizingStrategy=
Impl</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 strateg=
ies based on
+   requested content type. Each set has a name that is unique in the appli=
cation context
+   it is deployed in. The strategy can be refered to by this name. As a re=
sult of that
+   it is considered a named layout strategy in contrast to an anonymous st=
rategy 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 t=
here 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 dete=
rmined at all,
+   the request will proceed normally without invoking any strategy. Here i=
s an example
+   layout descriptor that defines a strategy for the layouts defined:
+   <programlisting>
+      <![CDATA[
+   <layouts>
+   <strategy content-type=3D"text/html">
+   <implementation>com.novell.portal.strategy.MaximizingStrategy</implemen=
tation>
+   </strategy>
+
+   <layout>
+   <name>generic</name>
+   <uri>/generic/index.jsp</uri>
+   <uri state=3D"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 fro=
m 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 r=
untime, and serves as a
+                  secondary query parameter to get the correct strategy fo=
r this content type out of
+                  the set that matches the name provided in the portal des=
criptor.
+               </para>
+            </sect3>
+         </sect2>
+         <sect2>
+            <title>Linking the Strategy and the Layout</title>
+            <para>As mentioned above, the layout descriptor can link a str=
ategy directly to the
+               layout. This will overwrite all other defined strategies fo=
r 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 d=
efined 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 assig=
nments. If there is no
-               particular strategy defined for the layout, then the page p=
roperty will overwrite the
-               portal property. If no strategy can be determined, then a l=
ast 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 stra=
tegy. Here is an example
-               layout descriptor that defines a strategy for the layouts d=
efined:
-               <programlisting>
-                  <![CDATA[
+            <para>The layout strategy can set a state to return to the por=
tal as a result of the
+               strategy evaluation. This state will be matched with the st=
ate attribute of the uri
+               element of the layout. If there is a match, then the uri th=
at matches this state will be
+               used as the layout for the current request. So, if the stra=
tegy sets a state of
+               'maximized' , the portal will try to use the layout resourc=
e that is pointed to for that
+               particular state in the currently selected layout. As you m=
ight 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=3D"text/html">
-               <implementation>com.novell.portal.strategy.MaximizingStrate=
gy</implementation>
-               </strategy>
-               =

                <layout>
-               <name>generic</name>
-               <uri>/generic/index.jsp</uri>
-               <uri state=3D"maximized">/generic/maximized.jsp</uri>
+               <name>industrial</name>
+               <uri>/industrial/index.jsp</uri>
+               <uri state=3D"maximized">/industrial/maximized.jsp</uri>
                </layout>
-               </layouts>
-               ]]></programlisting>
-               In this case the strategy is anonymous and directly assigne=
d to
-               the generic layout. The strategy cannot be discovered indep=
endently 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 des=
criptor and the layout
-               strategy descriptor. The content type is determined at runt=
ime, and serves as a
-               secondary query parameter to get the correct strategy for t=
his content type out of
-               the set that matches the name provided in the portal descri=
ptor.
+               </layouts>]]></programlisting>
+               In this case all reuquests that don't return a state
+               'maximized' from the evaluation of the strategy will use th=
e /industrial/index.jsp as
+               the layout. However, if the evaluation of the strategy retu=
rns 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 strate=
gy directly to the
-            layout. This will overwrite all other defined strategies for t=
he 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 strateg=
y sets a state of
-            'maximized' , the portal will try to use the layout resource t=
hat is pointed to for that
-            particular state in the currently selected layout. As you migh=
t 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=3D"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 lay=
out.
-         </para>
-      </sect2>
-   </sect1>
+         </sect2>
+      </sect1>
+   -->
    <sect1>
       <title>RenderSets</title>
       <sect2>

Added: docs/trunk/userGuide/en/images/intro/dashboard_add.gif
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- 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=3D"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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- 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=3D"images/intro/dashboard_add.gif" forma=
t=3D"gif" align=3D"center"
+                          valign=3D"middle"/>
+            </imageobject>
+         </mediaobject>
+         You are also able to add(clone) shared pages to your personal das=
hboard, by selecting the
+         <emphasis>Add to Dashboard</emphasis>
+         link. This will clone the page and add it to your personal dashbo=
ard as a page with the same name.
+      </para>
       <sect2 id=3D"dashboard_configure">
          <title>Configuring your personal dashboard</title>
          <para>


--===============1289461006903912294==--