Developing Portlets with the Bridge
This chapter demonstrates common development tasks described by the 301 specification.
Excluding Attributes from the Bridge Request Scope
When your application uses request attributes on a per request basis and you do not want that particular
attribute to be managed in the extended bridge request scope, you must use the following configuration in
your faces-config.xml. Below you will see that any attribute namespaced as foo.bar or any attribute beginning
with foo.baz(wildcard) will be excluded from the bridge request scope and only be used per that application's request.
Supporting PortletMode Changes
A PortletMode represents a distinct render path within an application. There are three standard modes: view,
edit, and help. The bridge's ExternalContext.encodeActionURL recognizes the query string parameter
javax.portlet.faces.PortletMode and uses this parameter's value to set the portlet mode on the underlying
portlet actionURL or response. Once processed it then removes this parameter from the query string. This means
the following navigation rule causes one to render the \edit.jspx viewId in the portlet edit mode:
Navigating to a mode's last viewId
By default a mode change will start in the mode's default view without any (prior) existing state. One common
portlet pattern when returning to the mode one left after entering another mode (e.g.. view -> edit -> view)
is to return to the last view (and state) of this origin mode. The bridge will explicitly encode the necessary
information so that when returning to a prior mode it can target the appropriate view and restore the appropriate state.
The session attributes maintained by the bridge are intended to be used by developers to navigate back from a
mode to the last location and state of a prior mode. As such a developer needs to describe a dynamic navigation:
"from view X return to the last view of mode y". This is most easily expressed via an EL expression. E.g.
Note to Portlet Developers
Depending on the bridge implementation, when using values from these session scoped attributes or any
viewIds which may contain query string parameters it may be necessary to use the wildcard syntax when
identifying the rule target. For example, the above ]]> expression returns a viewId of the
form Without wildcarding, when a subsequent navigation
occurs from this new view, the navigation rules wouldn't resolve because there wouldn't be an exact match.
Likewise, the above edit.jspx ]]> is wildcarded because there are navigation rules that target
it that use a query string ( /edit.jspx?javax.portlet.faces.PortletMode=edit ]]>).
Developers are encouraged to use such wildcarding to ensure they execute properly in the broadest set of