You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@myfaces.apache.org by so...@apache.org on 2010/05/27 00:43:29 UTC
svn commit: r948627 [3/3] - in /myfaces/portlet-bridge/tck/trunk: Portlet
1.0 Bridge for JavaServer Faces 1.2 TCK User's Guide.html TCK Tests.html
Modified: myfaces/portlet-bridge/tck/trunk/TCK Tests.html
URL: http://svn.apache.org/viewvc/myfaces/portlet-bridge/tck/trunk/TCK%20Tests.html?rev=948627&r1=948626&r2=948627&view=diff
==============================================================================
--- myfaces/portlet-bridge/tck/trunk/TCK Tests.html (original)
+++ myfaces/portlet-bridge/tck/trunk/TCK Tests.html Wed May 26 22:43:28 2010
@@ -1,1129 +1,2254 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
-<html><head>
-<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"><title>TCK Tests</title></head>
-<body>
-[<a name="NT"></a>NT] Not Testable<br>
-<div style="margin-left: 40px;">Unable to define a TCK
-test to verify the assertion in a manner that is implementation
-independent. I.e. the test won't work in every portlet
-container/app server environment. Note, in some circumstances the
-test is provided so it can be used to verify behavior/compliance in
-environments that do provide the necessary support.</div>
-<br>
-<br>
-<h2>Chapter 3 Tests</h2>
-[<a name="3.1"></a>3.1] <span style="color: rgb(0, 0, 0);">For this specification, the
-returned name must be "Portlet 1.0 Bridge for JavaServer Faces 1.2"<br>
-</span>
-<div style="margin-left: 40px;">Test:
- Write a portlet that gets Bridge API class and calls
-Class.getPackage to get the Specification Title and Version to compare
-with above statement. <br>
-</div>
-<br>
-[<a name="3.2"></a>3.2] The
-value <span style="font-family: monospace;">ALWAYS_DELEGATE</span>
-indicates the bridge should not render the view itself but rather
-always delegate the rendering.<br>
-<div style="margin-left: 40px;">Test:
- Run app with this config setting. Test by writing a
-ApplicationFactory to insert our own Application Impl that overrides
-setViewhandler which creates/installs the test ViewHandler before all
-others (on first call). In this text ViewHandlers render --
-check
-to see what the renderpolicy is and set an appropriate msg indicator on
-the request (attribute)</div>
-<br>
-[<a name="3.3"></a>3.3] <span style="color: rgb(0, 0, 0);">The value <span style="font-family: monospace;">NEVER_DELEGATE</span>
-indicates
-the bridge should always render the view itself and never delegate.<br>
-</span>
-<div style="margin-left: 40px;">Test: Run app
-with this config setting. Test by writing a
-ApplicationFactory to insert our own Application Impl that overrides
-setViewhandler which creates/installs the test ViewHandler before all
-others (on first call). In this text ViewHandlers render --
-check to
-see what the renderpolicy is and set an appropriate msg indicator on
-the request (attribute)</div>
-<br>
-[<a name="3.4"></a>3.4] <span style="color: rgb(0, 0, 0);"><span style="font-family: monospace;">DEFAULT</span>
-indicates .... the bridge to first delegate the
-render and if and only if an <span style="font-family: monospace;">Exception</span> is
-thrown then render the view based on its own logic</span><br>
-<div style="margin-left: 40px;">Test: Run app
-with this config setting. Test by writing a
-ApplicationFactory to insert our own Application Impl that overrides
-setViewhandler which creates/installs the test ViewHandler before all
-others (on first call). In this text ViewHandlers render --
-check to
-see what the renderpolicy is and set an appropriate msg indicator on
-the request (attribute)</div>
-<br>
-[<a name="3.5"></a>3.5] <span style="color: rgb(0, 0, 0);">If the
-configuration parameter is not present or has an invalid value the
-bridge renders
-using default behavior. I.e. as if <span style="font-family: monospace;">DEFAULT</span> is set</span><br>
-<div style="margin-left: 40px;">Test: Run app
-with this config setting. Test by writing a
-ApplicationFactory to insert our own Application Impl that overrides
-setViewhandler which creates/installs the test ViewHandler before all
-others (on first call). In this text ViewHandlers render --
-check to
-see what the renderpolicy is and set an appropriate msg indicator on
-the request (attribute)</div>
-<br>
-[<a name="3.6"></a>3.6] <span style="font-family: monospace;">LIFECYCLE_ID</span>
-is a <span style="font-family: monospace;">String</span>
-valued configuration parameter that describes the <span style="font-family: monospace;">ID</span> of the
-<span style="font-family: monospace;">Lifecycle</span>
-the bridge uses when executing Faces requests.<br>
-<div style="margin-left: 40px;">Test:
- Supply test FacesContextFactory. Create a new
-Lifecycle
-impl and register with its own ID. aka via faces-config.xml.
- Set init-param in web.xml to use. Verify in
-FacesContextFactory we are using this new Lifecycle -- test by getting
-the Lifecycle by ID and verifying that its the same instance as the one
-passed in.</div>
-<br>
-[<a name="3.7"></a>3.7] <span style="color: rgb(0, 0, 0);"> If not set the
-bridge uses the <span style="font-family: monospace;">ID</span>
-for the default lifecycle (<span style="font-family: monospace; color: rgb(0, 0, 0);">LifecycleFactory.DEFAULT_LIFECYCLE</span>)</span>.<br>
-<div style="margin-left: 40px;">Test:
- Supply test FacesContextFactory. Don't configure
-any
-specific Lifecycle to be used. Verify in FacesContxtFactory
-that
-we are using the default one.</div>
-<br style="color: black;">
-<span style="color: black;">[<a name="3.8"></a>3.8]
- </span><span style="font-family: monospace; color: black;">excludedRequestAttributes
-</span><span style="color: black;">is an
-attribute whose value is
-a <span style="font-family: monospace;">List</span>
-of <span style="font-family: monospace;">String</span>
-objects
-each of which either defines a specific attribute name the bridge is to
-exclude from its managed request scope or defines a set of
-attributes the bridge is to exclude from its managed request scope.<br>
-</span>
-<div style="margin-left: 40px; color: black;">Test: covered by
-6.1.3.1: requestMapRequestScopeTest -- which tests that exclusion works.</div>
-<span style="color: black;"><br>
-[<a name="3.9"></a>3.9] Such wildcard usage
-indicates the bridge is to exclude all those attributes within the
-namespace identified by removing the "*"</span>
-<div style="margin-left: 40px; color: black;">Test: covered by
-6.1.3.1: requestMapRequestScopeTest -- which tests that exclusion works.</div>
-<span style="color: black;"><br>
-[<a name="3.10"></a>3.10] </span><span style="font-family: monospace; color: black;">preserveActionParams</span><span style="color: black;">
-is a </span><span style="font-family: monospace; color: black;">Boolean</span><span style="color: black;">
-valued
-attribute that when </span><span style="font-family: monospace; color: black;">TRUE</span><span style="color: black;">
-indicates the bridge must maintain the
-action's request parameters for the duration of the bridge request
-scope.</span><br style="color: black;">
-<div style="margin-left: 40px; color: black;">Test:
-covered by 6.1.3.1: getRequestParameterPreserveParamsTest,
-getRequestParameterNamesPreserveParamsTest,
-getRequestParameterValuesMapPreserveParamsTest.</div>
-<br style="color: black;">
-<span style="color: black;">[<a name="3.11"></a>3.11]
-The exception to this
-is the </span><span style="font-family: monospace; color: black;">ResponseStateManager.VIEW_STATE_PARAM</span><span style="color: black;">
-parameter which is always maintained in the bridge request scope
-regardless of this setting. (I.e. always preserve the VIEW_STATE_PARAM
-regardless of preserveActionParams setting).</span><br style="color: black;">
-<div style="margin-left: 40px; color: black;">Test:
-covered by 6.1.3.1:getRequestParameterMapCoreTest,
-getRequestParameterNamesCoreTest,
- getRequestParameterValuesMapCoreTest.</div>
-<br>
-[<a name="3.12"></a>3.12] <span style="font-family: monospace; color: rgb(0, 0, 0);">defaultViewIdMap</span><span style="color: rgb(0, 0, 0);"> is a </span><span style="font-family: monospace; color: rgb(0, 0, 0);">Map<String,
-String></span><span style="color: rgb(0, 0, 0);">
-valued attribute containing one entry per supported </span><span style="font-family: monospace; color: rgb(0, 0, 0);">PortletMode</span><span style="color: rgb(0, 0, 0);">. </span><span style="font-family: monospace; color: rgb(0, 0, 0);">The Map</span><span style="color: rgb(0, 0, 0);"> key is the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">String</span><span style="color: rgb(0, 0, 0);"> name of the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">PortletMode</span><span style="color: rgb(0, 0, 0);">. The </span><span style="font-family: monospace; color: rgb(0, 0, 0);">Map</span><span style="color: rgb(0, 0, 0);"> value is the default Faces </span><span style="font-family: monospace; color: rgb(0, 0, 0);">viewId</span><span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);"> for the mode.<br>
-</span></span>
-<div style="margin-left: 40px;">Test: basically
-covered by any test. However add a test that supports
-a non-View mode (Edit) with a different viewId mapping. Then write a
-portlet that has an initial (non-JSF) render that adds a render link
-back to the portlet putting it in Edit mode. Verify our view
-is
-invoked.<br>
-</div>
-<span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);"><br>
-[<a name="3.13"></a>3.13] </span></span>Once
-destroy() has been called, no further requests can be processed through
-this bridge until a subsequent init() has occurred.<br>
-<div style="margin-left: 40px;">Test:
- subclass GFP, overriding the render behavior -- get the
-Bridge
-from GFP and then in a render call, init Bridge, destroy it,
-then
-call doFacesRequest(render) verify it fails as expected (i.e. throws
-UninitializedException). Do same but in processAction (i.e.
-destroy, followed by a doFacesRender)</div>
-<span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);"><br>
-[<a name="3.14"></a>3.14] </span></span>This
-call (destroy()) performs
-no action if the bridge is in an uninitialized state.<br>
-<div style="margin-left: 40px;">Test: Using test from <a href="#3.13">3.13</a> have it call destroy() a second
-time and verify that no exceptions are thrown.</div>
-<span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);"><br>
-[<a name="3.15"></a>3.15] </span></span><span style="font-family: monospace; color: rgb(0, 0, 0);">javax.portlet.faces.viewId:
-</span><span style="color: rgb(0, 0, 0);">The value
-of this attribute identifies the Faces </span><span style="font-family: monospace; color: rgb(0, 0, 0);">viewId</span><span style="color: rgb(0, 0, 0);">
-the bridge must use for this request (e.g. <span style="font-family: monospace;">/myFacesPage.jsp</span>).
- This is expected to be a valid Faces viewId though it may
-optionally contain a query string</span><br>
-<div style="margin-left: 40px;">Test:
- Write a portlet that has a default viewId of X.jsp but in its
-render sets the above attribute to y.jsp. Verify that y.jsp
-is
-activated. I.e. the X.jsp reports an error for the test
-while Y.jsp reports success. </div>
-<span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);"><br>
-[<a name="3.16"></a>3.16] </span></span><span style="font-family: monospace; color: rgb(0, 0, 0);">javax.portlet.faces.viewPath:
-</span><span style="color: rgb(0, 0, 0);">The value
-of this attribute contains the the Faces </span><span style="font-family: monospace; color: rgb(0, 0, 0);">viewId</span><span style="color: rgb(0, 0, 0);">
-the bridge must use for this request in <span style="font-family: monospace;">ContextPath</span>
-relative path form (e.g.<span style="font-family: monospace;">
-/faces/myFacesPage.jsp</span>). This value may
-optionally contain a query string.<br>
-</span>
-<div style="margin-left: 40px;">Test: Same test as <a href="#3.15">3.15</a> but set a path relative viewId.</div>
-<span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);"><br>
-<span style="color: black;">[<a name="3.17"></a>3.17]
-</span></span><span style="color: black;">The </span></span><span style="font-family: monospace; color: black;">BridgeUninitializedException</span><span style="color: black;"> is thrown if this
-method (doFacesRequest) is called while the bridge is in an
-uninitialized state</span><br style="color: black;">
-<div style="margin-left: 40px;"><span style="color: rgb(51, 51, 255);"><span style="color: black;">Test: covered by</span><span style="text-decoration: underline;"> </span></span><a href="TCK%20Tests.html#3.13">3.13</a><span style="color: rgb(51, 51, 255);"><span style="text-decoration: underline;"></span>.</span></div>
-<span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);"><br>
-[<a name="3.18"></a>3.18] </span></span><span style="color: rgb(0, 0, 0);">The </span><span style="font-family: monospace; color: rgb(0, 0, 0);">NullPointerException</span><span style="color: rgb(0, 0, 0);"> is thrown (from
-doFacesRequest()) if either the
-passed request or response objects are </span><span style="font-family: monospace; color: rgb(0, 0, 0);">null.<br>
-<br>
-</span>
-<div style="margin-left: 40px;">Test: call both action and
-render forms of doFacesRequest passing null. (Get bridge from
-GFP to do this).</div>
-<span style="font-family: monospace; color: rgb(0, 0, 0);"></span><span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);"><br>
-<br>
-</span></span>
-<h2><span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);">Chapter 4 Tests</span></span></h2>
-[<a name="4.1"></a>4.1] <span style="color: rgb(0, 0, 0);">In addition the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">GenericFacesPortlet</span><span style="color: rgb(0, 0, 0);">
-reads the following
-portlet initialization parameters and either sets the appropriate
-context attributes.<br>
-</span>
-<div style="margin-left: 40px;">Test: In the JSF
-Test read the portlet context init params that correspond to the one
-the GFP should be setting for each of these and make sure they have the
-same value as the ones in portlet.xml</div>
-<br>
-[<a name="4.2"></a>4.2] The <span style="font-family: monospace; color: rgb(0, 0, 0);">
-GenericFacesPortlet</span> overrides the <span style="font-family: monospace; color: rgb(0, 0, 0);">
-init()</span> method and
-does the following:<br><div style="margin-left: 40px;">Test:
- Subclass GFP and override init, call super(), override each of
-the methods its supposed to call -- verify they were called, verify
-appropriate context params set.</div><br>[<a name="4.3"></a>4.3] When not overridden by a subclass, the <span style="font-family: monospace;">GenericFacesPortlet</span>
-processes the request by first determining if the target of the request
-is a Faces or a nonFaces view. A nonFaces view target is
-recognized if the request contains the parameter <span style="font-family: monospace;">_jsfBridgeNonFacesView</span>. The value of this parameter is the <span style="font-family: monospace;">ContextPath</span> relative path to the nonFaces target. To handle this request the <span style="font-family: monospace;">GenericFacesPortlet</span>
-sets the response contentType, if not already set, using the preferred
-contentType expressed by the portlet container. It then uses a portlet <span style="font-family: monospace;">RequestDispatcher</span> to dispatch(include) the nonFaces target<div style="margin-left: 40px;">Test: Subclass GFP and overide render (to
-set the testname). Run test as a multirequest test. On
-action set the navigation (face-config.xml) to a viewId that is a
-nonFaces view (has the appropriate QS parameter.</div><br><span style="color: rgb(0, 0, 0);">[<a name="4.4"></a>4.4] If either the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">_jsfBridgeViewId</span><span style="color: rgb(0, 0, 0);"> parameter exists or both parameters exist and the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">_jsfBridgeViewId</span><span style="color: rgb(0, 0, 0);"> parameter value is non null, the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">GenericFacesPortlet</span><span style="color: rgb(0, 0, 0);"> must set the value of the request attribute </span><span style="font-family: monospace; color: rgb(0, 0, 0);">javax.portlet.faces.viewId</span><span style="color: rgb(0, 0, 0);"> to the value of the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">_jsfBridgeViewId</span><span style="color: rgb(0, 0, 0);"> parameter</span>.<br><div style="margin-left: 40px;">Test:
- Set the navigation rule to navigate to a response page but have
-in its query string both of the above (also pointing to the
-success page). Verify in the test that the attribute is set.</div><br><span style="color: rgb(0, 0, 0);">[<a name="4.5"></a>4.5] </span><span style="color: rgb(0, 0, 0);">If only the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">_jsfBridgeViewPath</span><span style="color: rgb(0, 0, 0);"> parameter exists and contains a non null value, the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">GenericFacesPortlet</span><span style="color: rgb(0, 0, 0);"> must set the value of the request attribute
-</span><span style="font-family: monospace; color: rgb(0, 0, 0);">javax.portlet.faces.viewPath</span><span style="color: rgb(0, 0, 0);"> to the value of the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">_jsfBridgeViewPath</span><span style="color: rgb(0, 0, 0);">
-parameter.</span><div style="margin-left: 40px;">Test:
- Set the navigation rule to navigate to a response page but have in
-its query string only the viewPath (also pointing to the success page).
- Verify in the test that the attribute is set.</div><br><span style="color: rgb(0, 0, 0);">[<a name="4.6"></a>4.6] </span>Otherwise the bridge is called without either of these attributes being set<span style="color: rgb(0, 0, 0);"></span>.<br><div style="margin-left: 40px;">Test:
- Set the navigation rule to navigate to a response page.
- Verify in the test that the attributes aren't set.</div><br>[<a name="4.7"></a>4.7] <span style="color: rgb(0, 0, 0);">
-The bridge calls this method during </span><span style="font-family: monospace; color: rgb(0, 0, 0);">init</span><span style="color: rgb(0, 0, 0);">(). </span><span style="font-family: monospace; color: rgb(0, 0, 0);">getBridgeClassName</span><span style="color: rgb(0, 0, 0);">
-returns the name of the class the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">GenericFacesPortlet</span><span style="color: rgb(0, 0, 0);"> uses to
-instantiate the bridge. The default (</span><span style="font-family: monospace; color: rgb(0, 0, 0);">GenericFacesPortlet</span><span style="color: rgb(0, 0, 0);">)
-implementation returns the value of the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">javax.portlet.faces.BridgeClassName
-PortletContext </span><span style="color: rgb(0, 0, 0);">initialization
-parameter, if it exists. If it doesn't exist, it
-calls <span style="font-family: monospace;"></span></span><span style="font-family: monospace; color: rgb(0, 0, 0);">getResourceAsStream()</span><span style="color: rgb(0, 0, 0);"> using the current thread's
-context class loader passing the resource path "</span><span style="font-family: monospace; color: rgb(0, 0, 0);">META-INF/services/javax.portlet.faces.Bridge</span><span style="color: rgb(0, 0, 0);">".
- It returns the first line of this stream excluding leading
-and
-trailing white space. If it can not resolve a class name, it throws a </span><span style="font-family: monospace; color: rgb(0, 0, 0);">PortletException</span><span style="color: rgb(0, 0, 0);"></span><br><div style="margin-left: 40px;">Test:
- override getBridgeClassName, have this method implement behavior
-as specified -- test that result is same as what super() returned.</div><br>[<a name="4.8"></a>4.8] <span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);">The default (</span></span><span style="font-family: monospace; color: rgb(0, 0, 0);">GenericFacesPortlet</span><span style="color: rgb(0, 0, 0);">)
-implementation of <span style="font-family: monospace;">getDefaultViewIdMap()</span> reads each portlet initialization parameter prefixed named </span><span style="font-family: monospace; color: rgb(0, 0, 0);">javax.portlet.faces.defaultViewId.[<span style="font-style: italic;">mode</span>]</span><span style="color: rgb(0, 0, 0);">
-where </span><span style="font-style: italic; color: rgb(0, 0, 0);">mode</span><span style="color: rgb(0, 0, 0);">
-is the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">String</span><span style="color: rgb(0, 0, 0);">
-form of a supported <span style="font-family: monospace;">PortletM</span></span><span style="font-family: monospace; color: rgb(0, 0, 0);">ode. </span><span style="color: rgb(0, 0, 0);">For each entry it adds a <span style="font-family: monospace;">Map</span> entry with mode as the key value and the initialization parameter value as the map value<br></span><div style="margin-left: 40px;">Test: override method, have this method get values as specified -- test that result is same as what super() returned.</div><br>[<a name="4.9"></a>4.9] <span style="color: rgb(0, 0, 0);">The default (</span><span style="font-family: monospace; color: rgb(0, 0, 0);">GenericFacesPortlet</span><span style="color: rgb(0, 0, 0);">)
-implementation for <span style="font-family: monospace;">getExcludedRequestAttributes()</span>
-returns a <span style="font-family: monospace;">List</span>
-constructed by parsing the comma delimited <span style="font-family: monospace;">String</span> value
-from the corresponding portlet initialization parameter, <span style="font-family: monospace;">javax.portlet.faces.excludedRequestAttributes.</span></span><span style="color: rgb(0, 0, 0);"></span><div style="margin-left: 40px;">Test: override method, have this method get values as specified -- test that result is same as what super() returned.</div><br>[<a name="4.10"></a>4.10] <span style="color: rgb(0, 0, 0);">If this initialization parameter isn't present <span style="font-family: monospace;">null</span> is
-returned which causes the <span style="font-family: monospace;">GenericFacesPortlet</span>
-to not set the corresponding <span style="font-family: monospace;">PortletContext</span>
-attribute.</span><span style="color: rgb(0, 0, 0);"></span><div style="margin-left: 40px;">Test: override method, have this method get values as specified -- test that result is same as what super() returned.</div><br>[<a name="4.11"></a>4.11] <span style="color: rgb(0, 0, 0);">The default (</span><span style="font-family: monospace; color: rgb(0, 0, 0);">GenericFacesPortlet</span><span style="color: rgb(0, 0, 0);">)
-implementation returns the </span><span style="font-family: monospace; color: rgb(0, 0, 0);"><span style="text-decoration: line-through; color: black;"></span><span style="color: black;">b</span>oolean</span><span style="color: rgb(0, 0, 0);"> value corresponding to the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">String</span><span style="color: rgb(0, 0, 0);"> value represented in the
-portlet initialization parameter, </span><span style="font-family: monospace; color: rgb(0, 0, 0);">javax.portlet.faces.preserveActionParams.</span><sup><span style="color: rgb(0, 0, 0);"></span></sup><span style="color: rgb(0, 0, 0);"></span><div style="margin-left: 40px;">Test: override method, have this method get values as specified -- test that result is same as what super() returned.</div><br>[<a name="4.12"></a>4.12] <span style="color: rgb(0, 0, 0);">If this
-initialization parameter doesn't exist, </span><span style="font-family: monospace; text-decoration: line-through; color: black;"></span><span style="color: black;"></span><span style="font-family: monospace; color: black;">false</span> is returned.<span style="color: rgb(0, 0, 0);"></span><div style="margin-left: 40px;">Test: override method, have this method get values as specified -- test that result is same as what super() returned.</div><br>[<a name="4.13"></a>4.13] <span style="color: rgb(0, 0, 0);"><span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);">If not overridden, the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">GenericFacesPortlet</span><span style="color: rgb(0, 0, 0);"> returns the value of the portlet initialization parameter </span><span style="font-family: monospace; color: rgb(0, 0, 0);">javax.portlet.faces.defaultContentType.</span></span></span><span style="color: rgb(0, 0, 0);"></span><div style="marg
in-left: 40px;">Test: override method, have this method get values as specified -- test that result is same as what super() returned.</div><br>[<a name="4.14"></a>4.14] <span style="color: rgb(0, 0, 0);"><span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);">If this parameter doesn't exists, the portlet container's indication of the preferred content type for this request.</span></span></span><span style="color: rgb(0, 0, 0);"></span><div style="margin-left: 40px;">Test: override method, have this method get values as specified -- test that result is same as what super() returned.</div><br>[<a name="4.15"></a>4.15] <span style="color: rgb(0, 0, 0);">The </span><span style="font-family: monospace; color: rgb(0, 0, 0);">GenericFacesPortlet</span><span style="color: rgb(0, 0, 0);"> implements </span><span style="font-family: monospace; color: rgb(0, 0, 0);">getResponseCharacterSetEncoding</span><span style="color: rgb(0, 0, 0);"> by returning
the value of the portlet initialization parameter </span><span style="font-family: monospace; color: rgb(0, 0, 0);">javax.portlet.faces.defaultCharacterSetEncoding</span><span style="color: rgb(0, 0, 0);">.</span><span style="color: rgb(0, 0, 0);"><span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);"></span></span></span><span style="color: rgb(0, 0, 0);"></span><div style="margin-left: 40px;">Test: override method, have this method get values as specified -- test that result is same as what super() returned.</div><br>[<a name="4.16"></a>4.16] <span style="color: rgb(0, 0, 0);">or </span><span style="font-family: monospace; color: rgb(0, 0, 0);">null</span><sup><span style="color: rgb(0, 0, 0);"></span></sup><span style="color: rgb(0, 0, 0);"> if this parameter doesn't exist.</span><span style="color: rgb(0, 0, 0);"></span><div style="margin-left: 40px;">Test: override method, have this method get values as specified -- test that result
is same as what super() returned.</div><br>[<a name="4.17"></a>4.17] <span style="color: black;">To support this the <span style="font-family: monospace;">GenericFacesPortlet</span>, via this method, returns a properly initialized and active bridge which a subclass can use to call one of the <span style="font-family: monospace;">doFacesRequest()</span> methods.</span><span style="color: rgb(0, 0, 0);"></span><div style="margin-left: 40px;">Test:
- override method, have this method get value as specified -- then
-call doFacesRequest() and see that all works right..</div><br><br>
-<h2><span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);"></span></span>Chapter
-5 Tests</h2><span style="color: black;">[</span><a style="color: black;" name="5.1"></a><span style="color: black;">5.1] This additional associated data
-includes (state stored in bridge request scope):</span><br style="color: rgb(204, 0, 0);"><div style="margin-left: 40px;"><span style="color: black;">Test:
- During action handling -- create all attributes/messages listed
-(including the excluded one's). On render verify what should be
-there is there and what shouldn't isn't. Test needs to render same view as runs in the action.</span> <br><span style="color: rgb(204, 0, 0);"></span></div><br>[<a name="5.2"></a>5.2] For each portlet action
-ignore any references to an existing request
-scope. I.e. portlet action requests always define the start of a new
-scope so never restore a preexisting one.<br><div style="margin-left: 40px;">Test: During an action -- add a request attribute, in a second action test and see that its not there.</div><br>[<a name="5.3"></a>5.3] Upon completion of each
-portlet
-action preserve the
-state described above in a newly created bridge request scope if the
-action doesn't terminate because of a redirect.<br><div style="margin-left: 40px;">Test:
- During an action -- add a request attribute, have the action's
-navigation rule indicate <redirect>, verify that during the
-render the attribute isn't there.</div>
-<br>[<a name="5.4"></a>5.4] ... the navigational
-target of the action doesn't specify a portlet mode that differs from
-the current request.<br><div style="margin-left: 40px;">Test:
- During an action -- add a request attribute, have the action's
-navigation encode a mode change, verify that during the render the
-atribute isn't there.</div><br>[<a name="5.5"></a>5.5] For each render request, the bridge identifies
-the corresponding bridge request scope <span style="color: rgb(0, 0, 0);">that pertains to this request
-and if one exists</span> it passes the
-state in this scope to the current (container) request scope.<br><div style="margin-left: 40px;">Test: Covered by test <a href="#5.1">5.1</a>.</div><br>[<a name="5.6"></a>5.6] For any action
-parameters that have been preserved, the parameter
-is restored if and only if there
-isn't an existing parameter of the same name in the incoming
-request.<br><div style="margin-left: 40px;">Test: set preserveActionParams. Cause an action (with parameters), verify in render the parameters are there.</div><br>[<a name="5.7"></a>5.7] This corresponds to ensuring that <span style="font-family: monospace;">ViewHandler.createView()</span>
-is used to establish the viewroot vs. <span style="font-family: monospace;">ViewHandler.restoreView()<br></span><div style="margin-left: 40px;">Test:
- Action followed by render, followed by render (redisplay but with
-a new Mode) -- verify that out test ViewHandler's createView is called
-not its restoreView.</div><br>[<a name="5.8"></a>5.8] Under normal conditions, a bridge request scope must be
-maintained
-at
-least until the<span style="color: rgb(255, 0, 0);"> <span style="color: rgb(0, 0, 0);">next action request (a
-subsequent bridge request scope is established)<br></span></span><div style="margin-left: 40px;">Test: Covered by <a href="#5.1">5.1</a></div><br>[<a name="5.9"></a>5.9] The bridge must not assume that all render requests
-following the
-establishment of a request scope (and prior to a subsequent action) are
-executed in the same bridge request scope.<br><div style="margin-left: 40px;">Test: Same type of test as 5.7 except add an attribute in the action and verify its not there in the redisplay.</div><br>[<a name="5.10"></a>5.10a-e] exclude attributes based on:<br><ul><li>an annotated bean</li><li>whose attribute name is listed as an excluded
-attribute using the <<span style="font-style: italic;">bridge</span>:excluded-attributes> ... in faces-config.xml</li><li>whose attribute name is in the immediate namespace listed
-as a
-wildcarded excluded attribute using the <<span style="font-style: italic;">bridge</span>:excluded-attributes> ... in faces-config.xml</li><li>whose attribute name appears in the <span style="font-family: monospace;"></span><span style="font-family: monospace;">List</span> object of
-excluded attributes in the portlet context attribute <tt>javax.portlet.faces.[<span style="font-style: italic;">portlet name</span>].excludedRequestAttributes</tt></li><li>whose attribute name appears in the immediate
-namespace listed as a
-wildcarded excluded attribute in the <span style="font-family: monospace;">List</span> object of
-excluded attributes in the portlet context attribute <tt>javax.portlet.faces.[<span style="font-style: italic;">portlet name</span>].excludedRequestAttributes</tt></li></ul><div style="margin-left: 40px;">Test:
- In action add request M request attributes -- some to test each
-of the 4 conditions above -- others to test the inverse -- that other
-attributes are retained.</div><br>[<a name="5.11"></a>5.11] <span style="color: rgb(0, 0, 0);">The JSF 1.2
-specification, section 6.1.5 requires that the various <span style="font-family: monospace;">FacesContext</span>
-methods that get <span style="font-family: monospace;">Messages</span>
-return those <span style="font-family: monospace;">Messages</span>
-in insertion order. The bridge must preserve this requirement while
-managing such <span style="font-family: monospace;">Messages</span>
-within the bridge request scope.<br></span><div style="margin-left: 40px;">Test: Covered by #<a href="#5.1">5.1</a> -- the message portion of the test adds 2 messages to the UIView root and verifies they come back in the same order.</div><br>[<a name="5.12"></a>5.12]
-
-For each <span style="font-family: monospace;">doFacesRequest</span>
-invocation processing a Faces target,
-the bridge must acquire a <span style="font-family: monospace;">FacesContext</span>
-object. The bridge must acquire the <span style="font-family: monospace;">FacesContext</span> by
-calling the <span style="font-family: monospace;">FacesContextFactory.<br></span><div style="margin-left: 40px;">Test: 5.13 because it runs in the FacesContextFactory verifies this as well.</div><br>[<a name="5.13"></a>5.13]
-
-The <span style="font-family: monospace;">FacesContext</span>
-is acquired from the factory by passing the corresponding <span style="font-family: monospace; color: black;">PortletContext</span><span style="color: black;">, </span><span style="font-family: monospace; color: black;">PortletRequest</span><span style="color: black;">, </span><span style="font-family: monospace; color: black;">PortletResponse</span> objects and the <span style="font-family: monospace;">Lifecycle</span> ...<br><div style="margin-left: 40px;">Test: In own FacesContextFactory -- verify that the correct types of objects are passed when acquiring the FacesContext.</div><br>[<a name="5.14"></a>5.14]
-
-Prior to acquiring the <span style="font-family: monospace;">FacesContextFactory</span><span style="font-family: monospace;"></span>
-the bridge is required to set the
-following request attribute on the passed request object.<br><div style="margin-left: 40px;">Test: In FacesContextFactory confirm that the attribute is set with the correct value.</div><br>[<a name="5.15"></a>5.15] If the request attribute named <span style="font-family: monospace;">javax.portlet.faces.viewId</span>
-is non null then use this value as the target <span style="font-family: monospace;">viewId<br></span><div style="margin-left: 40px;">Test: Covered by test <a href="#3.15">3.15</a></div><br>[<a name="5.16"></a>5.16] If the request attribute named <span style="font-family: monospace;">javax.portlet.faces.viewPath</span>
-is non null then use this value to process the <span style="font-family: monospace;">ContextPath</span>
-relative path and extract the target <span style="font-family: monospace;">viewId<br></span><div style="margin-left: 40px;">Test: Covered by test <a href="#3.16">3.16</a></div><br>[<a name="5.17"></a>5.17] If unable to extract a <span style="font-family: monospace;">viewId</span> from the
-path throw<span style="font-family: monospace;">
-javax.portlet.faces.BridgeInvalidViewPathException<br></span><div style="margin-left: 40px;">Test:
- Added new arm to the Test portlet built for test 3.15/3.16.
- This portlet now also passes an invalid path via the attribute
-and verifies the exception is thrown.</div><br>[<a name="5.18"></a>5.18] If the bridge is processing for the target view in a render
-request which occurs in the same portlet mode following another render
-request in which a redirect occurred and an action request hasn't been
-processed in the meantime, use the target <span style="font-family: monospace;">viewId</span> from the
-prior redirect.<br><div style="margin-left: 40px;">Test:
- Action navigates to render page which has a render redirect to a
-page that has a redisplay on it. Verify that the redisplay
-renders the redirected page.</div><br>[<a name="5.19"></a>5.19] Use this
- <span style="font-family: monospace;">viewId</span>,
-if and only if, the current portlet mode is the same as the portlet
-mode in which the <span style="font-family: monospace;">viewId</span>
-was encoded into the response<br><div style="margin-left: 40px;">Test: Verify that the current
-ViewId is ignored when redisplay in a new mode: Use test that
-includes a redisplay link (to the currentView but with a new mode).
- Define in portlet.xml that the new mode (edit) default view is a
-different view. Verify that when the redisplay/new mode occurs
-you are on the default view page not the original view page.</div><br>[<a name="5.20"></a>5.20] If the bridge can't
-locate a default <span style="font-family: monospace;">viewId</span>
-for the current portlet mode or that default is <span style="font-family: monospace;">null</span>, throw <span style="font-family: monospace;">javax.portlet.faces.BridgeDefaultViewNotSpecifiedException<br></span><div style="margin-left: 40px;">Test:
- Use a view that includes a redisplay link to the currentView but
-in a different mode. Don't define a default viewId for the new
-mode (but do define that the mode is supported). Write a portlet
-that catches the expected exceptionto verify the result. </div><br>[<a name="5.21"></a>5.21] <span style="color: rgb(0, 0, 0);"> When a query string is encountered the bridge must extract
-this
-information as part of its process of determining the viewId and expose
-the parameters in this query string as additional request parameters.<br></span><div style="margin-left: 40px;">Test:
- 2 Tests: One where the default viewId contains the QS param
-and a second where the portlet sets the ViewId (on an attribute) with a
-QS param. </div><br>[<a name="5.22"></a>5.22] throw the
-BridgeUninitializedException if the bridge isn't currently initialized (<span style="font-family: monospace;">init()</span> has been
-called following either the bridge's construction or a prior <span style="font-family: monospace;">release()</span>) (action)<br><div style="margin-left: 40px;">Test: Covered by the action destroy portion of test #<a href="#3.13">3.13</a></div><br>[<a name="5.23"></a>5.23] set the <span style="font-family: monospace;">javax.portlet.faces.phase</span>
-request attribute to <span style="font-family: monospace;">Bridge.PortletPhase.ACTION_PHASE</span>
-prior to acquiring the <span style="font-family: monospace;">FacesContext<br></span><div style="margin-left: 40px;">Test: Covered by test #<a href="#5.14">5.14</a></div><br>[<a name="5.24"></a>5.24] <span style="color: rgb(0, 0, 0);">recognize
-whether Faces considers the current request processing complete
-(redirect occurred) or not. If its not considered complete ... (set up action response correctly)<br></span><div style="margin-left: 40px;">Test: Covered by any of our action based scope tests. Test #<a href="#5.1">5.1</a></div><br>[<a name="5.25"></a>5.25] release the <span style="font-family: monospace;">FacesContext</span> (at end of action)<span style="font-family: monospace;"><br></span><div style="margin-left: 40px;">Test: In test FacesContext set a request attribute on release() -- test in portlet that the attribute is there.</div><br>[<a name="5.26"></a>5.26] remove the <span style="font-family: monospace;">javax.portlet.faces.phase</span> request attribute (at end of action)<br><div style="margin-left: 40px;">Test: In portlet that the attribute isn't there after action processing finishes.</div><br>[<a name="5.27"></a>5.27] throw the
-BridgeUninitializedException if the bridge isn't currently initialized (<span style="font-family: monospace;">init()</span> has been
-called following either the bridge's construction or a prior <span style="font-family: monospace;">release()</span>) (render)<br><div style="margin-left: 40px;">Test: Covered by the action destroy portion of test #<a href="TCK%20Tests.html#3.13">3.13</a></div><br>[<a name="5.28"></a>5.28] set the <span style="font-family: monospace;">javax.portlet.faces.phase</span>
-request attribute to <span style="font-family: monospace;">Bridge.PortletPhase.RENDER_PHASE</span>
-prior to acquiring the <span style="font-family: monospace;">FacesContext.<br></span><div style="margin-left: 40px;">Test: Covered by test #<a href="TCK%20Tests.html#5.14">5.14</a></div><br>[<a name="5.29"></a>5.29] If <span style="font-family: monospace;"><span style="color: rgb(0, 0, 0);">RenderResponse</span>.getContentType()</span>returns
-null and there is no other indication of desired content type (not
-defined by this specification; i.e. an implementation specific
-extension) then the bridge must
-call <span style="font-family: monospace;"><span style="color: rgb(0, 0, 0);">RenderResponse</span>.setContentType()</span>
-passing the value returned from <span style="font-family: monospace; color: rgb(0, 0, 0);">RenderRequest.getResponseContentType()<br></span><div style="margin-left: 40px;">Test:
-Have portlet call doFacesRequest directly without setting the
-ContentType -- check in the render portion of Test that the response
-ContentType is the one requested (i.e. it was set by the Bridge)</div><br>[<a name="5.30"></a>5.30] reestablish (if so
-indicated) the Faces request scope from the corresponding bridge
-request scope satisfying
-all requirements listed in section <a href="Chapter%205%20Bridge%20Lifecycle%20Requirements.html#PLT_5.1.2">5.1.2</a>
-concerning providing an
-idempotent rendition based on the <span style="font-family: monospace;">viewId</span>
-and request scope state
-referenced in the render request.<br><div style="margin-left: 40px;">Test: Covered by Test #<a href="#5.1">5.1</a></div><br><span style="color: black;">[<a name="5.31"></a>5.31] ensure
-the </span><span style="font-family: monospace; color: black;">RenderKit's</span><span style="color: black;">
- </span><span style="font-family: monospace; color: black;">ResponseStateManager</span><span style="color: black;">
- </span><span style="font-family: monospace; color: black;">isPostback()</span><span style="color: black;">
-method returns true if
-and only if a bridge request scope has been identified and restored</span><br><div style="margin-left: 40px;">Test: In render following action -- test that <span style="font-family: monospace; color: black;">ResponseStateManager</span><span style="color: black;">
- </span><span style="font-family: monospace; color: black;">isPostback() </span><span style="color: black;">returns true.</span></div><br>[<a name="5.32"></a>5.32] <span style="color: rgb(51, 51, 255);"><span style="color: black;">manually restore the view from its cache if the view hasn't yet been saved by Faces</span><br></span><div style="margin-left: 40px;">Test: Covered by Test #<a href="TCK%20Tests.html#5.1">5.1</a></div><br><span style="color: black;">[<a name="5.33"></a>5.33a-b] ensure that all </span><span style="font-family: monospace; color: black;">PhaseListeners</span><span style="color: black;">
-listening on the </span><span style="font-family: monospace; color: black;">before</span><span style="color: black;">
- and </span><span style="font-family: monospace; color: black;">after</span><span style="color: black;">
-phase of the</span><span style="font-family: monospace; color: black;"> PhaseId.RESTORE_VIEW</span><span style="color: black;"> are
-called</span><br><div style="margin-left: 40px;">Test: Have test implement/add
-itself as PhaseListener -- in before/after, test that we are in render
-phase and if so set attribute that our listener was called.
- verify these attributes in test's render. Note:
- verify that the other action phases aren't called by also
-listening on them,</div><br>[<a name="5.34"></a>5.34] execute the <span style="font-family: monospace;">render</span>
-phase of the Faces lifecycle.<br><div style="margin-left: 40px;">Test:
- Any of the existing tests verify this in that all ultimately
-render a jsf view which can't happen unless this phase happens.</div><br>[<a name="5.35"></a>5.35] <span style="color: rgb(0, 0, 0);">recognize
-if a redirect
-occurs during this render process and handle by discarding any existing
-output, and rerunning this process based on the new target and its
-request parameters (if the target has a query string).<br></span><div style="margin-left: 40px;">Test: Covered by Test #<a href="#5.18">5.18</a></div><br>[<a name="5.36"></a>5.36] if necessary, update the value of the<span style="font-family: monospace;"> VIEW_STATE_PARAM</span>
-parameter managed in this bridge request scope.<br><div style="margin-left: 40px;">Test: Covered by RenderRedisplayTest #5.8. I.e. since this test puts an attribute on the request in the action
-and verifies its still there after the redisplay the VIEW_STATE_PARAM
-must have been updated (internally) or else the view couldn't have been
-restored properly. Note: the messages tests also verify
-this.</div><br>[<a name="5.37"></a>5.37] <span style="color: rgb(0, 0, 0);">release the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">FacesContext</span><span style="color: rgb(0, 0, 0);"> (render).<br></span><div style="margin-left: 40px;">Test: Same logic as #<a href="#5.27">5.27</a> except check in the render phase not during an action.</div><br>[<a name="5.38"></a>5.38] remove the <span style="font-family: monospace;">javax.portlet.faces.phase</span> request attribute<span style="font-family: monospace; color: rgb(0, 0, 0);"></span><span style="color: rgb(0, 0, 0);"> (render).<br></span><div style="margin-left: 40px;">Test: Same logic as #<a href="TCK%20Tests.html#5.28">5.28</a> except check in the render phase not during an action.</div><br>[<a name="5.39"></a>5.39] If it is not (the same mode), this target viewId must be
-ignored
-and the mode's default viewId used instead<br><div style="margin-left: 40px;">Test: Covered by #<a href="#5.19">5.19</a> test -- i.e. this test changes the mode in the redisplay link -- the
-portlet.xml defines a different view as the default edit mode view --
-it verifies we end up at the default edit view -- hence verifing this
-assertion.</div><br>[<a name="5.40"></a>5.40] the bridge must not restore the
-encoded bridge request scope if the portlet mode has changed.
- I.e. bridge request scopes are maintained on a per mode basis
-and
-must only be used when you (re)render in the same mode.<br><div style="margin-left: 40px;">Test: Cover by #<a href="#5.4">5.4</a></div><br>[<a name="5.41"></a>5.41] the bridge must ensure
-that the VIEW_STATE_PARAM request parameter is not exposed during a
-render in which the mode has changed. Typically this occurs
-automatically as a result of not restoring the bridge request scope<br><div style="margin-left: 40px;">Test: From action encodes its navigation rule to change to edit mode. In render, check that the parameter isn't set.</div><br>[<a name="5.42"></a>5.42] <span style="color: rgb(0, 0, 0);">This means the following navigation rule
-causes
-one to render the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">\edit.jspx
-viewId</span><span style="color: rgb(0, 0, 0);"> in
-the portlet </span><span style="font-style: italic; color: rgb(0, 0, 0);">edit</span><span style="color: rgb(0, 0, 0);"> mode.<br></span><div style="margin-left: 40px;">Test: Covered by many tests. Here is are the baseic ones: #<a href="#6.11">6.11</a> and #<a href="#6.19">6.19</a></div><br>[<a name="5.43"></a>5.43] the bridge must maintain a set of session attributes
-named <span style="font-family: monospace;">javax.portlet.faces.viewIdHistory.[</span><span style="font-style: italic; font-family: monospace;">mode</span><span style="font-family: monospace;">]</span> where there
-is one such attribute per supported portlet mode.<br><div style="margin-left: 40px;">Test:
- Set up portlet with 3 modes and 3 default views. In render
-verify there are the three associated mode/history attributes in the session each with the default view as its value.</div><br>[<a name="5.44"></a>5.44] The value
-of this attribute is the last <span style="font-family: monospace;">viewId</span>
-that was active for a given mode.<br><div style="margin-left: 40px;">Test: Covered by #5.47</div><br>[<a name="5.45"></a>5.45] If a mode has never been active than
-this attribute's value must be the same as the that mode's default <span style="font-family: monospace;">viewId.<br></span><div style="margin-left: 40px;">Test: Covered by #5.43</div><br>[<a name="5.46"></a>5.46] These extra parameters must be encoded in the <span style="font-family: monospace;">viewId</span> in a
-manner that conforms to JSF expectations for valid <span style="font-family: monospace;">viewIds</span> and
-which will be processed correctly when passed through the calls <span style="font-family: monospace;">ViewHandler.getActionURL</span>
-and the bridge's <span style="font-family: monospace;">ExternalContext.encodeActionURL</span>
-such that it results in a valid portlet <span style="font-family: monospace;">actionURL</span>
-and/or <span style="font-family: monospace;">actionResponse</span>
-which not only targets the associated <span style="font-family: monospace;">viewId</span> in the
-associated <span style="font-family: monospace;">PortletMode</span>
-but also returns to that view with the same state (both in the bridge's
-request scope, view state, and any other render parameters) as existed
-when this view was added to the history list.<br><div style="margin-left: 40px;">Test: Covered by #5.47</div><br>[<a name="5.47"></a>5.47] the bridge must allow,
-recognize, and evaluate faces-config.xml navigation rules where the
-<to-view-id> element is a JSF expression.<br><div style="margin-left: 40px;">Test:
- Page 1 (view mode) navigates to Page 2 (view mode). Set a
-render parameter while in page 2. Navigate
-to page 3 (edit mode). Have a nav rule from page 3 to mathc the
-syntax in the spec for returning to the prior view in the prior mode.
- Verify that we go back to page 2 and that the render parameter is
-still available.</div><br><br><h2>Chapter 6 Tests</h2>[<a name="6.1"></a>6.1] The file
-<span style="font-family: monospace;">META-INF/services/javax.faces.context.FacesContextFactory</span>
-contains the
-name of the bridge's concrete <span style="font-family: monospace;">FacesContextFactory</span>
-implementation
-class.<br><div style="margin-left: 40px;">Test:
-Write a portlet that does the same work that the GFP would do -- reads
-this file and verifies the class. Have the portlet output the
-response directly.</div><br>[<a name="6.2"></a>6.2]
-The bridge must not assume that the <span style="font-family: monospace;">FacesContext</span>
-returned by calling <span style="font-family: monospace;">getFacesContext</span> is
-an <span style="font-style: italic;">instanceof</span>
-its <span style="font-family: monospace;">FacesContext</span>
-implementation class.<br><div style="margin-left: 40px;">Test:
-Have the TCK provide its own FacesContextFactory impl wrapping
-the bridges. Test is that the JSF page can perform and
-action/render.</div><br>[<a name="6.3"></a>6.3] (dispatch) Dispatch a request to the specified resource to create
-output for this response. This must be accomplished by calling the <code>javax.portlet.PortletContext</code>
-method <code>getRequestDispatcher()</code>, and calling
-the <code>include().</code><div style="margin-left: 40px;">Test:
-In the render portion of the test check that the
-javax.servlet.include.servletPath exists as this indicates an include
-happend.</div><br>[<a name="6.4"></a>6.4] (encodeActionURL) If the <span style="font-family: monospace;">inputURL
-</span>starts with the # character
-return the <span style="font-family: monospace;">inputURL
-</span>unchanged.<div style="margin-left: 40px;">Test: In the render portion of the test call encodeActionURL passing an URL that begins with #.</div><br>[<a name="6.5"></a>6.5] (encodeActionURL) If the <span style="font-family: monospace;">inputURL</span><span style="font-family: monospace;"></span>
-is an
-absolute path external to this portlet application
-return the <span style="font-family: monospace;">inputURL
-</span>unchanged<div style="margin-left: 40px;">Test: In the render portion of the test call encodeActionURL passing an absolute URL.</div><br>[<a name="6.6"></a>6.6] (encodeActionURL) If the <span style="font-family: monospace;">inputURL
-</span>contains the
-parameter <span style="font-family: monospace;">javax.portlet.faces.DirectLink</span>
-and its value is <span style="font-family: monospace;">true</span>
-then
-return it without removing this parameter.<div style="margin-left: 40px;">Test: In
-the render portion of the test call encodeActionURL passing an URL
-containing the DirectLink parameter set to true.</div><br>[<a name="6.7"></a>6.7] (encodeActionURL) If the <span style="font-family: monospace;">inputURL
-</span>contains the
-parameter <span style="font-family: monospace;">javax.portlet.faces.DirectLink</span>
-and its value is <span style="font-family: monospace;">false</span>
-then remove the <span style="font-family: monospace;">javax.portlet.faces.DirectLink</span>
-parameter and its value from the query string and continue processing.<div style="margin-left: 40px;">Test: In
-the render portion of the test call encodeActionURL passing an URL
-containing the DirectLink parameter set to false.</div><br>[<a name="6.8"></a>6.8] (encodeActionURL) The scheme is followed by either the keyword <span style="font-family: monospace;">render</span> or <span style="font-family: monospace;">action</span>.
- <span style="font-family: monospace;">render</span> indicates
-a portlet <span style="font-family: monospace;">renderURL</span>
-should be encoded.<div style="margin-left: 40px;">Test:
-Use encodeActionURL to encode portlet:render?params url. Verify
-that the result is the same as calling toString on createRenderURL()</div><br>[<a name="6.9"></a>6.9] (encodeActionURL) <span style="font-family: monospace;">action</span>
-indicates a portlet <span style="font-family: monospace;">actionURL</span>
-should be encoded.<div style="margin-left: 40px;">Test: Use encodeActionURL to encode portlet:action?params url. Verify that
-the result is the same as calling toString on createActionURL()</div><br>[<a name="6.10"></a>6.10] (encodeActionURL) If it is a reference to a Faces view the target is the
-encoded Faces <span style="font-family: monospace;">viewId</span>.<div style="margin-left: 40px;">Test:
-Write test that submits an action and renders result of test (in
-render). If the result is rendered we successfully navigated
-across an action -- ergo the viewId has to have been encoded someplace.</div><br>[<a name="6.11"></a>6.11] (encodeActionURL) recognize the query string parameter <span style="font-family: monospace;">javax.portlet.faces.PortletMode</span>
-and use the value of this parameter to identify the mode that should be
-encoded in the generated reference. (During action)<div style="margin-left: 40px;">Test: Have test's action target contain QS parameter for switching mode. Test in render that we are in that mode.</div><br>[<a name="6.12"></a>6.12] (encodeActionURL) If the value doesn't
-identify
-a valid mode then no encoding action is taken. (During action)<div style="margin-left: 40px;">Test: Have
-test's action target contain QS parameter for switching mode but to a
-mode that doesn't exist (for this portlet). Test in render that
-we are still in "view" mode.</div><br>[<a name="613"></a>6.13] (encodeActionURL) recognize the query string parameter <span style="font-family: monospace;">javax.portlet.faces.WindowState</span>
-and use the value of this parameter to identify the window state that
-should be
-encoded in the generated reference (During action)<div style="margin-left: 40px;">Test: Have
-test's action target contain QS parameter for changing WindowState.
- Test in render that we are in that window state.</div><br>[<a name="6.14"></a>6.14] (encodeActionURL) If
-the value doesn't
-identify a valid window state then no encoding action is
-taken. (During action)<div style="margin-left: 40px;">Test: Have test's action target contain QS parameter for switching window state but
-to a state that doesn't exist (for this portlet). Test in render that
-we are still in "normal" mode.</div><br>[<a name="6.15"></a>6.15] (encodeActionURL) recognize the query string parameter <span style="font-family: monospace;">javax.portlet.faces.Secure </span>and
-use the value of this parameter to identify the security level that
-should be
-encoded in the generated reference (During action)<div style="margin-left: 40px;">Test: Have
-test's action target contain security parameter for changing Security.
- Test in render that we are in that security state.<br><br><span style="color: black; font-weight: bold;">Note:
- as not all portlet containers support changing this state, this
-may not be testable in many environments and hence isn't a required TCK
-test.</span></div><br>[<a name="6.16"></a>6.16] (encodeActionURL) A value of <span style="font-family: monospace;">true</span>
-or <span style="font-family: monospace;">false</span>
-is translated into the <span style="font-family: monospace;">boolean</span>
-<span style="font-family: monospace;">true</span>/<span style="font-family: monospace;">false</span>
-respectively
-regardless of case. Any
-other value is ignored. (During action)<div style="margin-left: 40px;">Test: Have
-test's action target contain invalid security parameter value for
-changing Security. Test in render that we are in normal state.<br><br><span style="color: black; font-weight: bold;">Note:
- as not all portlet containers support changing this state, this
-may not be testable in many environments and hence isn't a required TCK
-test.</span></div><br>[<a name="6.17"></a>6.17] (encodeActionURL) All other query string parameters are added to the <span style="font-family: monospace;">PortletURL</span><span style="font-family: monospace;"></span> as parameters. (During action)<div style="margin-left: 40px;">Test: Have test's action target contain additional QS params. Test in render that we received them back.</div><br>[<a name="6.18"></a>6.18] (encodeActionURL) If it is a reference to a Faces view the target is the
-encoded Faces <span style="font-family: monospace;">viewId</span>. (During render)<div style="margin-left: 40px;">Test: Basically the same test as #<a href="#6.10">6.10</a>.
- If we can render a page contining a form (link) and navigate
-through it then the first render must have properly encoded the target
-view id.</div><br>[<a name="6.19"></a>6.19] (encodeActionURL) recognize the query string parameter <span style="font-family: monospace;">javax.portlet.faces.PortletMode</span>
-and use the value of this parameter to identify the mode that should be
-encoded in the generated reference. (During render)<div style="margin-left: 40px;">Test:
-Have a TCK viewHandler that in its getActionURL returns an URL with the
-QS parameter set to switch the mode. When action is submitted,
-test that the mode is switched. </div><br>[<a name="6.20"></a>6.20] (encodeActionURL) If the value doesn't
-identify
-a valid mode then no encoding action is taken. (During render)<div style="margin-left: 40px;">Test: Have a TCK viewHandler that in its getActionURL returns an URL with the
-QS parameter set to an invalid mode. When action is submitted, test
-that the mode isn't switched.</div><br>[<a name="6.21"></a>6.21] (encodeActionURL) recognize the query string parameter <span style="font-family: monospace;">javax.portlet.faces.WindowState</span>
-and use the value of this parameter to identify the window state that
-should be
-encoded in the generated reference (During render)<div style="margin-left: 40px;">Test: Have a TCK viewHandler that in its getActionURL returns an URL with the
-QS parameter set to switch the window state. When action is submitted, test
-that the window state is switched. </div><br>[<a name="6.22"></a>6.22] (encodeActionURL) If
-the value doesn't
-identify a valid window state then no encoding action is
-taken. (During render)<div style="margin-left: 40px;">Test: Have a TCK viewHandler that in its getActionURL returns an URL with the
-QS parameter set to an invalid window state. When action is submitted, test
-that the window state isn't switched.</div><br>[<a name="6.23"></a>6.23] (encodeActionURL) recognize the query string parameter <span style="font-family: monospace;">javax.portlet.faces.Secure </span>and
-use the value of this parameter to identify the security level that
-should be
-encoded in the generated reference (During render)<div style="margin-left: 40px;">Test: Have a TCK viewHandler that in its getActionURL returns an URL with the
-QS parameter set to secure (mode). When action is submitted, test
-that we are in secure mode<br><br>.<span style="color: black; font-weight: bold;">Note:
- as not all portlet containers support changing this state, this
-may not be testable in many environments and hence isn't a required TCK
-test.</span> </div><br>[<a name="6.24"></a>6.24] (encodeActionURL) A value of <span style="font-family: monospace;">true</span>
-or <span style="font-family: monospace;">false</span>
-is translated into the <span style="font-family: monospace;">boolean</span>
-<span style="font-family: monospace;">true</span>/<span style="font-family: monospace;">false</span>
-respectively
-regardless of case. Any
-other value is ignored. (During render)<div style="margin-left: 40px;">Test: Have a TCK viewHandler that in its getActionURL returns an URL with the
-QS parameter set to an invalid secure mode value. When action is submitted, test
-that the secure mode isn't switched.<br><br><span style="color: black; font-weight: bold;">Note:
- as not all portlet containers support changing this state, this
-may not be testable in many environments and hence isn't a required TCK
-test.</span> </div><br>[<a name="6.25"></a>6.25] (encodeActionURL) All other query string parameters are added to the <span style="font-family: monospace;">PortletURL</span><span style="font-family: monospace;"></span> as parameters. (During render)<div style="margin-left: 40px;">Test: Have
-a TCK viewHandler that in its getActionURL returns an URL with the
-regulaar parameter set to some known value. When action is
-submitted, test
-that the parameter is received and has the known value. </div><br>[<a name="6.26"></a>6.26] (encodeResourceURL) <span style="color: black;">If the </span><span style="font-family: monospace; color: black;">inputURL</span><span style="color: black;"> is </span><span style="font-style: italic; color: black;">opaque</span><span style="color: black;">, in that it is an absolute <span style="font-family: monospace;">URI</span> with a
-scheme-specific part that doesn't begin with a slash character (e.g. </span><span style="font-family: monospace; color: black;">mailto:java-net@java.sun.com</span><span style="color: rgb(51, 51, 255);"><span style="color: black;">), return the </span><span style="font-family: monospace; color: black;">inputURL</span><span style="color: black;"> unchanged</span></span><div style="margin-left: 40px;">Test: During render call encodeResourceURL with an opaqueURL and verify its uncahnged.</div><br>[<a name="6.27"></a>6.27] (encodeResourceURL) check to see if the <span style="font-family: monospace;">inputURL</span>
-contains a query string parameter named <span style="font-family: monospace;">javax.portlet.faces.BackLink</span>.
- If it does replace it with a parameter whose name is the
-value of this parameter and whose value is the <span style="font-family: monospace;">String</span> (<span style="font-family: monospace;">URL</span> path)
-returned after calling <span style="font-family: monospace;">ViewHandler.getActionURL()</span>
-passing the current <span style="font-family: monospace;">viewId</span>
-followed by <span style="font-family: monospace;">ExternalContext.encodeActionURL()</span><div style="margin-left: 40px;">Test:
-In render, call encodeResourceURL with the BackLink param -- compare it
-to the value from calling encodeActionURL(getActionURL(currentViewId))</div><br>[<a name="6.28"></a>6.28] (encodeResourceURL) return <span style="font-family: monospace;">getResponse().encodeURL(inputURL) </span>(foreign resource URL)<div style="margin-left: 40px;">Test:
- During render: pass a foreign resource URl to encodeResourceURL
--- test that the return is the same as passing the same string to
-getResponse.encodeURL()</div><br>[<a name="6.29"></a>6.29] (encodeResourceURL) If <span style="font-family: monospace;">inputURL</span> is a
-relative <span style="font-family: monospace;">URL</span>
-(i.e. it is
-neither absolute nor starts with a '/') then the <span style="font-family: monospace;">inputURL</span> must
-be
-turned into a context path relative <span style="font-family: monospace;">URL</span> by
-constructing a new url based
-on going relative to the current path. The current path is
-defined as the path that would be used to <span style="font-family: monospace;">dispatch()</span> to
-the current view. Return <span style="font-family: monospace;">getResponse().encodeURL(inputURL)</span><div style="margin-left: 40px;">Test:
- During render: call encodeResourceURL passing a relative URL --
-test that the return is the same as passing the full path URL to
-response.encodeResourceURL()</div><br>[<a name="6.30"></a>6.30] (encodeResourceURL) If
-the <span style="font-family: monospace;">inputURL</span>
-<span style="color: black;">is </span><span style="font-style: italic; color: black;">hierarchical</span><span style="color: black;"> and</span> targets a resource
-that is within this application ... If the resulting <span style="font-family: monospace;">inputURL</span>
-contains a query string parameter named <span style="font-family: monospace;">javax.portlet.faces.BackLink</span>
-then replace it with a parameter whose name is the value of this
-parameter and whose value is the <span style="font-family: monospace;">String</span> (<span style="font-family: monospace;">URL</span> path)
-returned after calling <span style="font-family: monospace;">ViewHandler.getActionURL()</span>
-passing the current <span style="font-family: monospace;">viewId</span>
-followed by <span style="font-family: monospace;">ExternalContext.encodeActionURL().</span><div style="margin-left: 40px;">Test:
-During render: call encodeResourceURL with an relative URL with a
-BackLink param -- verify that the URL is correctly ouput with a correct
-backlink</div><br>[<a name="6.31"></a>6.31] (encodeResourceURL) If
-the <span style="font-family: monospace;">inputURL</span>
-<span style="color: black;">is </span><span style="font-style: italic; color: black;">hierarchical</span><span style="color: black;"> and</span> targets a resource
-that is within this application ... Ensure that the <span style="font-family: monospace;">inputURL</span>
-(potentially modified by the previous step) is a fully qualified path <span style="font-family: monospace;">URI</span>
-(i.e.contains the context path)<div style="margin-left: 40px;">Test: During render: call encodeResourceURL with a context path relative URL -- verify the result is a fully qaulified URI</div><br>[<a name="6.32"></a>6.32] (encodeResourceURL) If
-the <span style="font-family: monospace;">inputURL</span>
-<span style="color: black;">is </span><span style="font-style: italic; color: black;">hierarchical</span><span style="color: black;"> and</span> targets a resource
-that is within this application ... If the resulting <span style="font-family: monospace;">inputURL</span>
-contains a query string parameter named <span style="font-family: monospace;">javax.portlet.faces.BackLink</span>
-then replace it with a parameter whose name is the value of this
-parameter and whose value is the <span style="font-family: monospace;">String</span> (<span style="font-family: monospace;">URL</span> path)
-returned after calling <span style="font-family: monospace;">ViewHandler.getActionURL()</span>
-passing the current <span style="font-family: monospace;">viewId</span>
-followed by <span style="font-family: monospace;">ExternalContext.encodeActionURL()</span><div style="margin-left: 40px;">Test: During
-render: call encodeResourceURL with a context path relative URL
-with a backLink param -- verify the result is a fully qaulified URI and
-contains a valid Backlink</div><br>[<a name="6.33"></a>6.33] (encodeResourceURL) If the resulting <span style="font-family: monospace;">inputURL</span>
-contains a query string parameter named <span style="font-family: monospace;">javax.portlet.faces.ViewLink</span>
-then remove this query string parameter and value from the <span style="font-family: monospace;">inputURL</span>.
- If the value of this parameter was"<span style="font-family: monospace;">true</span>" return
-the result of calling <span style="font-family: monospace;">encodeActionURL(inputURL)</span><div style="margin-left: 40px;">Test: During render: call encodeResourceURL with a context path relative URL
-with a viewLink param -- verify the result is same as calling encodeActionURL.</div><br>[<a name="6.34"></a>6.34] (encodeResourceURL) If the resulting <span style="font-family: monospace;">inputURL</span>
-contains a query string parameter named <span style="font-family: monospace;">javax.portlet.faces.ViewLink</span>
-then remove this query string parameter and value from the <span style="font-family: monospace;">inputURL</span>.
- If the value of this parameter was"<span style="font-family: monospace;">true</span>" return
-the result of calling <span style="font-family: monospace;">encodeActionURL(inputURL) +<br></span>If the resulting <span style="font-family: monospace;">inputURL</span>
-contains a query string parameter named <span style="font-family: monospace;">javax.portlet.faces.BackLink</span>
-then replace it with a parameter whose name is the value of this
-parameter and whose value is the <span style="font-family: monospace;">String</span> (<span style="font-family: monospace;">URL</span> path)
-returned after calling <span style="font-family: monospace;">ViewHandler.getActionURL()</span>
-passing the current <span style="font-family: monospace;">viewId</span>
-followed by <span style="font-family: monospace;">ExternalContext.encodeActionURL()</span><div style="margin-left: 40px;">Test: During
-render: call encodeResourceURL with a context path relative URL
-with a viewLink param and backLink param -- verify the result is same
-as calling encodeActionURL and has a correctly encoded backLink</div><br>[<a name="6.35"></a>6.35] (setRequest) This must be the last request object set as a
-consequence of calling <span style="font-family: monospace;">setRequest().<br></span><div style="margin-left: 40px;">Test: In action set a new request object and then get it to see that get returns the newly set object.</div><br>[<a name="6.36"></a>
-6.36] (setCharacterSetEncoding) Overrides the name of the character encoding used in the
-body of this request. Calling
-this method during the <span style="font-family: monospace;">RENDER_PHASE</span> <span style="text-decoration: line-through;"></span>has no
-effect and throws no exceptions<div style="margin-left: 40px;">Test: Call during render phase and verify that an Exception isn't thrown.</div><br>[<a name="6.37"></a>6.37] (setCharacterSetEncoding) Overrides the name of the character encoding used in the
-body of this request.<div style="margin-left: 40px;">Test: Call during action and verify its set by calling getCharacterSetEncoding.</div><br>[<a name="6.38"></a>6.38] (getRequestHeaderMap) Return an immutable <code>Map</code> whose keys are the
-set of request header names included in the current request, and whose
-values (of type <span style="font-family: monospace;">String</span>)
-are the first (or only) value for each header
-name returned by the underlying request. <span style="color: rgb(0, 0, 0);">Within a </span><span style="font-family: monospace; color: rgb(0, 0, 0);">RENDER_REQUEST</span><span style="color: rgb(0, 0, 0);">, the map must exclude the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">CONTENT-TYPE</span><span style="color: rgb(0, 0, 0);"> property (if it is present
-in the underlying request). </span>When executing during a <span style="font-family: monospace;">RENDER_PHASE</span>
-the bridge must only ensure that <span style="font-family: monospace;">Accept</span> and <span style="font-family: monospace;">Accept-Language</span>
-exist (and as noted above that <span style="font-family: monospace;">Content-Type</span>
-doesn't exist).<div style="margin-left: 40px;">Test:
-During Render: call getRequestHeaderMap -- verify map is
-immutable, contains same values as request.getPropertyXXX, plus the
-Accept and Accept-Language, minus Content-Type.</div><br>[<a name="6.39"></a>6.39] (getRequestHeaderMap) Return an immutable <code>Map</code> whose keys are the
-set of request header names included in the current request, and whose
-values (of type <span style="font-family: monospace;">String</span>)
-are the first (or only) value for each header
-name returned by the underlying request. In addition, to provide compatibility with servlets, the
-bridge must ensure that the following entries exist in the <span style="font-family: monospace;">Map</span><span style="color: rgb(51, 51, 255);"></span> and the
-bridge is
-executing during an <span style="font-family: monospace;">ACTION_PHASE</span>:
- <span style="font-family: monospace;">Accept</span>,
-<span style="font-family: monospace;">Accept-Language</span>,
-<span style="font-family: monospace;">Content-Type</span>,
-and <span style="font-family: monospace;">Content-Length</span><div style="margin-left: 40px;">Test: During Action: call getRequestHeaderMap -- verify map is immutable,
-contains same values as request.getPropertyXXX, plus the Accept, Accept-Language, and Content-Type.</div><br>[<a name="6.40"></a>6.40] (getRequestHeaderValuesMap) Return an immutable <code>Map</code> whose
-keys are the set of request header names included in the current
-request, and whose values (of type <span style="font-family: monospace;">String[]</span>) are
-all of the value for
-each header name returned by the underlying request <span style="color: rgb(0, 0, 0);">Within a </span><span style="font-family: monospace; color: rgb(0, 0, 0);">RENDER_REQUEST</span><span style="color: rgb(0, 0, 0);">, the map must exclude the </span><span style="font-family: monospace; color: rgb(0, 0, 0);">CONTENT-TYPE</span><span style="color: rgb(0, 0, 0);"> property (if it is present
-in the underlying request). </span>When executing during a <span style="font-family: monospace;">RENDER_PHASE</span>
-the bridge must only ensure that <span style="font-family: monospace;">Accept</span> and <span style="font-family: monospace;">Accept-Language</span>
-exist (and as noted above that <span style="font-family: monospace;">Content-Type</span>
-doesn't exist).<div style="margin-left: 40px;">Test:
-During Render: call getRequestHeaderValuesMap -- verify map is immutable,
-contains same values as request.getPropertyXXX, plus the Accept and
-Accept-Language, minus Content-Type.</div><br>[<a name="6.41"></a>6.41] (getRequestHeaderValuesMap) Return an immutable <code>Map</code> whose keys are the
-set of request header names included in the current request, and whose
-values (of type <span style="font-family: monospace;">String</span>)
-are the first (or only) value for each header
-name returned by the underlying request. In addition, to provide compatibility with servlets, the
-bridge must ensure that the following entries exist in the <span style="font-family: monospace;">Map</span><span style="color: rgb(51, 51, 255);"></span> and the
-bridge is
-executing during an <span style="font-family: monospace;">ACTION_PHASE</span>:
- <span style="font-family: monospace;">Accept</span>,
-<span style="font-family: monospace;">Accept-Language</span>,
-<span style="font-family: monospace;">Content-Type</span>,
-and <span style="font-family: monospace;">Content-Length</span><div style="margin-left: 40px;">Test: During Action: call getRequestHeaderValuesMap -- verify map is immutable,
-contains same values as request.getPropertyXXX, plus the Accept, Accept-Language, and Content-Type.</div><br>[<a name="6.42"></a>6.42] (getRequestMap) Return a mutable <code>Map</code>
-representing the request scope attributes for the current application..... operations must take the
-appropriate action on the underlying data structure<div style="margin-left: 40px;">Test:
-During render: add two request attrs, one via ExternalContext api
-and other using the protlet api, verify both can be read using both
-APIs. Verify that remove works by doing the reverse. </div><br>[<a name="6.43"></a>6.43] (getRequestMap) Furthermore these attributes must be managed across portlet
-requests according to the rules defined in section <a href="Chapter%205%20Bridge%20Lifecycle%20Requirements.html#PLT_5.1.2">[5.1.2]</a><div style="margin-left: 40px;">Test:
-During action add a set of requet attrs that will test all cases of
-attrs that should be retained in scope and attrs that should not be.
- During render, verify that only those that should be retained are
-there.</div><br>[<a name="6.44"></a>6.44] (getRequestMap) If the attribute is included in the bridge request scope then
-regardless of whether the attribute is a managed-bean or not, if the
-attribute's value has one or more public
-no-argument void return methods annotated with <code>javax.portlet.faces.annotation.BridgePreDestroy</code>,
-then each such method must be called before the
-element is removed from the underlying data structure.<div style="margin-left: 40px;">Test:
- Have a request scoped managed bean that records whether its
-predestroy methods have been properly called (puts values into request
-scope). Now remove the bean. Test that the expected request
-scope attrs indicating predestroy sequence are there.<br><br><span style="font-weight: bold;">Note:
- This test will not work in Portals that rely on servlet
-cross-context dispatching to execute portlets as the required context
-listeners aren't called across the contexts.</span></div><br>[<a name="6.45"></a>6.45] (getRequestParameterMap) Return an immutable <code>Map</code> whose keys are the
-set of request parameters names included in the current request, and
-whose values (of type String) are the first (or only) value for each
-parameter name returned by the underlying request. In addition, during a portlet's <span style="font-family: monospace;">RENDER_PHASE</span>, <span style="color: rgb(0, 0, 0);">if not
-otherwise already in the <span style="font-family: monospace;">Map</span></span>,
-the bridge must include those parameters managed in the corresponding
-bridge request scope. This always includes the <span style="font-family: monospace;">ResponseStateManger.VIEW_STATE_PARAM</span>
-parameter<div style="margin-left: 40px;">Test:
-Provide form with two input fields with preset values, on action verify
-that the input fields/values are there. During render (that follows
-this action) verify the parameters aren't there but the VIEW_STATE
-param is.</div> <br>[<a name="6.46"></a>6.46] (getRequestParameterMap) The preservation/inclusion of the rest of the
-action parameters depends on the <span style="font-family: monospace;">javax.portlet.faces.[</span><span style="font-style: italic; font-family: monospace;">portlet
-name</span><span style="font-family: monospace;">].<span style="color: rgb(0, 0, 0);">preserveActionParams</span>
-</span>portlet
-context attribute. If this context attribute exists and has a
-value of <span style="font-family: monospace;">Boolean.TRUE</span>,
-<span style="color: rgb(0, 0, 0);">the additional
-action parameters are preserved/included.</span><div style="margin-left: 40px;">Test: Have portlet configure this. Use same test as #<a href="#6.45">6.45</a> but verify that the form params are also there during render.</div><br>[<a name="6.47"></a>6.47] (getRequestParameterMap) <span style="color: rgb(0, 0, 0);">T</span>his <span style="font-family: monospace;">Map</span> must be
-composed from the
-set of parameters available via the <code>javax.portlet.PortletRequest</code>
-methods <code>getParameter()</code> and <code>getParameterNames()</code>
-plus any additional parameter names encoded in the (query string) of
-the <span style="font-family: monospace;">viewId</span><div style="margin-left: 40px;">Test: Have the default viewid of the portlet contain QS params. During render verify that these params are there.</div><br>[<a name="6.48"></a>6.48] (getRequestParameterNames) Return an <code>Iterator</code> over the names of all
-request parameters included in the current request. In addition, during a portlet's <span style="font-family: monospace;">RENDER_PHASE</span>, <span style="color: rgb(0, 0, 0);">if not
-otherwise already in the <span style="font-family: monospace;">Iterator</span>,</span>
-the bridge must include those parameter names managed in the
-corresponding bridge request scope. This always includes the <span style="font-family: monospace;">ResponseStateManger.VIEW_STATE_PARAM</span>
-parameter. <div style="margin-left: 40px;">Test:
-Provide form with two input fields with preset values, on action verify
-that the input fields/values are there. During render (that follows
-this action) verify the parameters aren't there but the VIEW_STATE
-param is.</div><br>[<a name="6.49"></a>6.49] (getRequestParameterNames) The preservation/inclusion of the rest of the
-action parameters depends on the <span style="font-family: monospace;">javax.portlet.faces.[</span><span style="font-style: italic; font-family: monospace;">portlet
-name</span><span style="font-family: monospace;">].<span style="color: rgb(0, 0, 0);">preserveActionParams</span>
-</span>portlet
-context attribute. If this context attribute exists and has a
-value of <span style="font-family: monospace;">Boolean.TRUE</span>,
-<span style="color: rgb(0, 0, 0);">the additional
-action parameters are preserved/included.</span><div style="margin-left: 40px;">Test: Have portlet configure this. Use same test as #<a href="TCK%20Tests.html#6.49">6.49</a> but verify that the form params are also there during render.</div><br>[<a name="6.50"></a>6.50] (getRequestParameterNames) <span style="color: rgb(0, 0, 0);">T</span>his <span style="font-family: monospace;">Iterator</span> must be
-composed from the
-set of parameters available via the <code>javax.portlet.PortletRequest</code>
-methods <code>getParameter()</code> and <code>getParameterNames()</code>
-plus any additional parameter names encoded in the (query string) of
-the <span style="font-family: monospace;">viewId</span><div style="margin-left: 40px;">Test: Have the default viewid of the portlet contain QS params. During render verify that these params are there.</div><br>[<a name="6.51"></a>6.51] (getRequestParameterValuesMap) Return an immutable <code>Map</code> whose
-keys are the set of request parameters names included in the current
-request, and whose values (of type String[]) are all of the values for
-each parameter name returned by the underlying request In addition, during a portlet's <span style="font-family: monospace;">RENDER_PHASE</span>, <span style="color: rgb(0, 0, 0);">if not
-otherwise already in the <span style="font-family: monospace;">Map</span></span>,
-the bridge must include those parameters managed in the corresponding
-bridge request scope. This always includes the <span style="font-family: monospace;">ResponseStateManger.VIEW_STATE_PARAM</span>
-parameter<div style="margin-left: 40px;">Test:
-Provide form with two input fields with preset values, on action verify
-that the input fields/values are there. During render (that follows
-this action) verify the parameters aren't there but the VIEW_STATE
-param is.</div><br>[<a name="6.52"></a>6.52] (getRequestParameterValuesMap) The preservation/inclusion of the rest of the
-action parameters depends on the <span style="font-family: monospace;">javax.portlet.faces.[</span><span style="font-style: italic; font-family: monospace;">portlet
-name</span><span style="font-family: monospace;">].<span style="color: rgb(0, 0, 0);">preserveActionParams</span>
-</span>portlet
-context attribute. If this context attribute exists and has a
-value of <span style="font-family: monospace;">Boolean.TRUE</span>,
-<span style="color: rgb(0, 0, 0);">the additional
-action parameters are preserved/included.</span><div style="margin-left: 40px;">Test: Have portlet configure this. Use same test as #<a href="TCK%20Tests.html#6.51">6.51</a> but verify that the form params are also there during render.</div><br>[<a name="6.53"></a>6.53] (getRequestParameterValuesMap) <span style="color: rgb(0, 0, 0);">T</span>his <span style="font-family: monospace;">Map</span> must be
-composed from the
-set of parameters available via the <code>javax.portlet.PortletRequest</code>
-methods <code>getParameter()</code> and <code>getParameterNames()</code>
-plus any additional parameter names encoded in the (query string) of
-the <span style="font-family: monospace;">viewId</span><div style="margin-left: 40px;">Test: Have the default viewid of the portlet contain QS params. During render verify that these params are there.</div><br>[<a name="6.54"></a>6.54] (getRequestPathInfo) Return the extra path information (if any) included in the request <span style="font-family: monospace;">URI</span>;
-otherwise, return <code>null</code>.
- This value must represent the path portion of the current
-target <span style="font-family: monospace;">viewId</span>. Because the portlet model doesn't support a (servlet) equivalent notion
-of <span style="font-family: monospace;">pathInfo</span>
-and <span style="font-family: monospace;">servletPath</span>,
-the bridge must manufacture these values based on the target <span style="font-family: monospace;">viewId</span>.
- The bridge determines the target view from request
-parameter(s)
-it has previously encoded. If this information doesn't exist, the
-target view is the default <span style="font-family: monospace;">viewId</span>
-defined by the portlet. The associated pathInfo and
-servletPath
-are constructed by determining the servlet mapping of the Faces servlet
-and constructing the appropriate paths such that they conform to the
-paths the servlet container generates when processing an http request
-which targets this view as defined in SRV .4.4 in the Servlet 2.5
[... 2544 lines stripped ...]