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. foo.bar foo.baz.* ]]>
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: /register.jspx edit /edit.jspx?javax.portlet.faces.PortletMode=edit ]]>
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. /edit.jspx* view #{sessionScope['javax.portlet.faces.viewIdHistory.view']} ]]> 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 bridge implementations.