You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bridges-commits@portals.apache.org by at...@apache.org on 2007/02/23 03:51:47 UTC

svn commit: r510776 - /portals/bridges/trunk/struts/xdocs/features.xml

Author: ate
Date: Thu Feb 22 18:51:46 2007
New Revision: 510776

URL: http://svn.apache.org/viewvc?view=rev&rev=510776
Log:
Documentation for the "prefix" RenderAttributes functionality, See: PB-12

Modified:
    portals/bridges/trunk/struts/xdocs/features.xml

Modified: portals/bridges/trunk/struts/xdocs/features.xml
URL: http://svn.apache.org/viewvc/portals/bridges/trunk/struts/xdocs/features.xml?view=diff&rev=510776&r1=510775&r2=510776
==============================================================================
--- portals/bridges/trunk/struts/xdocs/features.xml (original)
+++ portals/bridges/trunk/struts/xdocs/features.xml Thu Feb 22 18:51:46 2007
@@ -248,6 +248,7 @@
               <render-context>
                 <attribute name="errors"/>
                 <attribute name="message" keep="true"/>
+                <attribute prefix="com.foo.bar" keep="true"/>
               </render-context>
             </config>]]></source>
           <em>(This (adapted) example is taken from the JPetstore Portlet example provided with the
@@ -259,13 +260,17 @@
           will be restored until the next ActionRequest or when the Struts Page URL is changed. 
         </p>
         <p>
+          Furthermore, every request attribute which name start with <em>com.foo.bar</em> is also saved after the ActionRequest.
+          With the "prefix" attribute type definition, a whole range of attributes can be configured at once.
+        </p>
+        <p>
           Using the RenderContextAttributes configuration, a Struts Action can still forward (without redirecting) to a
           JSP in a Portlet while passing its required data through the request attributes. Request scoped ActionForms
           can also safely be used for this as the Struts Bridge will automatically remove them from the session again
           when they go out of scope!      
         </p>
         <p>
-          Using the "single use only" configuration (without the keep="true" attribute) allows one to pass on rather large
+          Using the "single use only" configuration (meaning: without the keep="true" attribute) allows one to pass on rather large
           objects to the RenderRequest because, even if they are stored in the Session, this will only be for a very
           short period (milliseconds). Of course, with a subsequent RenderRequest these objects won't be available
           anymore and the specific View Renderer must be able to handle that situation properly.<br/>
@@ -471,7 +476,7 @@
           Servlet directly, not through the Portlet), this Servlet won't "see" the previously APPLICATION_SCOPE Session attributes anymore.<br/>
           This can be an issue for features like binary file (pdf) rendering through a servlet which needs to use the Session to access its data.
           To solve this, the utility 
-          <a href="../portals-bridges-common/apidocs/org/apache/portals/bridges/util/PortletWindowUtils.html">PortletWindowUtils</a> class can
+          <a href="../portals-bridges-common/apidocs/org/apache/portals/bridges/util/PortletWindowUtils.html" target="_nw">PortletWindowUtils</a> class can
           be used which provides methods to access a specific Portlet instance its PORTLET_SCOPE session attributes based on its PortletWindowId.<br/>
           That PortletWindowId (which a Portlet can retrieve itself using the PortletWindowUtils) needs to be passed on to the Servlet first
           (for example as query-string parameter on a link send to the browser) for it to be able to make use of it.



---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-commits-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-commits-help@portals.apache.org