Apache Struts 2 Documentation > Home > Guides > Core Developers Guide > Portlet Configuration |

Apache Struts 2 Documentation
Portlet Configuration
Edit Page Browse Space Add Page Add News
Added by nilsga, last edited by Ted Husted on Jan 15, 2007 (view change)

| The Portlet support is experimental. Feedback is appreciated!

## Portlet Init Parameters

Below is the init-param elements that you can set up in portlet.xml for configuring the portlet mode -> xwork namespace mappings for the portlet. Basically, you can think of the different portlet modes as different sub-applications, so it can be useful to set up the `struts.xml` configuration with different namespaces for the different portlets and modes:

Key | Description | Default
--- | --- | ---
portletNamespace | The namespace for the portlet in the action configuration. This namespace is prepended to all action lookups, and makes it possible to host multiple portlets in the same portlet application. If this parameter is set, the complete namespace will be /portletNamespace/modeNamespace/actionName | The default namespace.
viewNamespace | The namespace in the xwork config for the view portlet mode. | The default namespace.
editNamespace | The namespace in the xwork config for the edit portlet mode. | The default namespace.
helpNamespace | The namespace in the xwork config for the help portlet mode. | The default namespace.
defaultViewAction | Name of the action to use as default for the view portlet mode, when no action name is present. | default
defaultEditAction | Name of the action to use as default for the edit portlet mode, when no action name is present. | default
defaultHelpAction | Name of the action to use as default for the help portlet mode, when no action name is present. | default

e.g.

portlet.xml

    <init-param>
        <!-- Portlet namespace -->
        <name>portletNamespace</name>
        <value>/portletA</value>
    </init-param>
    <init-param>
        <!-- The base namespace of the view portlet mode -->
        <name>viewNamespace</name>
        <value>/view</value>
    </init-param>
    <init-param>
        <!-- The default action to invoke in view mode -->
        <name>defaultViewAction</name>
        <value>index</value>
    </init-param>

This snippet from `portlet.xml` will set up the portlet with a namespace of /portletA/. This means that all requests to this portlet will get the namespace prepended when looking up the action. In addition, the _view portlet mode will map to the /view namespace, so a request for action `myAction` will resolve to the namespace and action /portletA/view/myAction. It also means that if no action is requested, the default action of `index` will be used for the request.

## Portlet Phases

The portlet specification describes that a portlet request cycle can consist of two phases, an event phase and a render phase. In case of an event in the portlet, it will always execute before the render phase. The event phase is typically for changing the state of the application. In a portlet, this is typically when a form is submitted. The render phase will then prepare and dispatch to the view. It's recommended that you set up the result from an action that is executed in the event phase to point to another action that is executed in the render phase, which again is responsible for dispatching to the actual view.

## Portlet Result Dispatching

The webwork-portlet-default package defines a special default Result Type, which is responsible for performing the result logic of an Action execution. Typically, this involves including a JSP for rendering, or preparing a render action if one is configured for the current event action.

This result type has three main modes of execution.

- If the Action is executed in the render phase, it will perform a PortletRequestDispatcher.include(req, res) to the resource specified in the location attribute.
- If the Action is executed in the event phase, and the result is an action mapping, it will set a render parameter on the ActionResponse to indicate which Action should be executed in the render phase. This follows good web application design, which promotes the use of a redirect after an event, which in this case means that an Action executed in the event phase will be followed by a redirect to an Action executed in the render phase.
- If the Action is executed in the event phase, and the result is not an action mapping, the result will prepare a special Action called "renderDirect" (specified in the webwork-portlet-default package) whose sole purpose is to render the specified web resource (usually a JSP).

The action executed in event mode can pass render parameters to the next action to execute in render mode through a query string in the result configuration:

    <result name="success">/displayCart.action?userId=${userId}</result>

This will set up a render parameter called userId with the value of the userId property of the dispatching action.