public abstract class AbstractController extends PortletContentGenerator implements Controller
As stated in the Controller
interface, a lot of functionality is already provided by certain abstract
base controllers. The AbstractController is one of the most important
abstract base controller providing basic features such controlling if a
session is required and render caching.
Workflow
(and that defined by interface):
handleActionRequest
will be called by the DispatcherPortlet once to perform the action defined by this
controller.handleActionRequestInternal
,
(optionally synchronizing around the call on the PortletSession),
which should be overridden by extending classes to provide actual functionality to
perform the desired action of the controller. This will be executed only once.handleRenderRequest
will be called by the DispatcherPortlet
repeatedly to render the display defined by this controller.handleRenderRequestInternal
,
(optionally synchronizing around the call on the PortletSession),
which should be overridden by extending classes to provide actual functionality to
return ModelAndView
objects.
This will be executed repeatedly as the portal updates the current displayed page.Exposed configuration properties
(and those defined by interface):
name | default | description |
requireSession | false | whether a session should be required for requests to be able to be handled by this controller. This ensures, derived controller can - without fear of Nullpointers - call request.getSession() to retrieve a session. If no session can be found while processing the request, a PortletException will be thrown |
synchronizeOnSession | false | whether the calls to handleRenderRequestInternal and
handleRenderRequestInternal should be
synchronized around the PortletSession, to serialize invocations
from the same client. No effect if there is no PortletSession.
|
cacheSeconds | -1 | indicates the amount of seconds to specify caching is allowed in the render response generatedby this request. 0 (zero) will indicate no caching is allowed at all, -1 (the default) will not override the portlet configuration and any positive number will cause the render response to declare the amount indicated as seconds to cache the content |
renderWhenMinimized | false | whether should be rendered when the portlet is in a minimized state -- will return null for the ModelandView when the portlet is minimized and this is false |
TIP: The controller mapping will be run twice by the PortletDispatcher for
action requests -- once for the action phase and again for the render phase. You can
reach the render phase of a different controller by simply changing the values for the
criteria your mapping is using, such as portlet mode or a request parameter, during the
action phase of your controller. This is very handy since redirects within the portlet
are apparently impossible. Before doing this, it is usually wise to call
clearAllRenderParameters
and then explicitly set all the parameters that
you want the new controller to see. This avoids unexpected parameters from being passed
to the render phase of the second controller, such as the parameter indicating a form
submit ocurred in an AbstractFormController
.
Thanks to Rainer Schmitz and Nick Lothian for their suggestions!
ResourceAwareController
,
EventAwareController
Modifier and Type | Field and Description |
---|---|
private boolean |
renderWhenMinimized |
private boolean |
synchronizeOnSession |
logger
Constructor and Description |
---|
AbstractController() |
Modifier and Type | Method and Description |
---|---|
void |
handleActionRequest(ActionRequest request,
ActionResponse response)
Process the action request.
|
protected void |
handleActionRequestInternal(ActionRequest request,
ActionResponse response)
Subclasses are meant to override this method if the controller
is expected to handle action requests.
|
ModelAndView |
handleRenderRequest(RenderRequest request,
RenderResponse response)
Process the render request and return a ModelAndView object which the DispatcherPortlet
will render.
|
protected ModelAndView |
handleRenderRequestInternal(RenderRequest request,
RenderResponse response)
Subclasses are meant to override this method if the controller
is expected to handle render requests.
|
boolean |
isRenderWhenMinimized()
Return whether controller will render when portlet is minimized.
|
boolean |
isSynchronizeOnSession()
Return whether controller execution should be synchronized on the session.
|
void |
setRenderWhenMinimized(boolean renderWhenMinimized)
Set if the controller should render an view when the portlet is in
a minimized window.
|
void |
setSynchronizeOnSession(boolean synchronizeOnSession)
Set if controller execution should be synchronized on the session,
to serialize parallel invocations from the same client.
|
applyCacheSeconds, cacheForSeconds, check, checkAndPrepare, checkAndPrepare, getCacheSeconds, isRequireSession, preventCaching, setCacheSeconds, setRequireSession
getPortletContext, getTempDir, isContextRequired, setPortletContext
getApplicationContext, getMessageSourceAccessor, initApplicationContext, initApplicationContext, requiredContextClass, setApplicationContext
private boolean synchronizeOnSession
private boolean renderWhenMinimized
public final void setSynchronizeOnSession(boolean synchronizeOnSession)
More specifically, the execution of the handleActionRequestInternal
method will get synchronized if this flag is "true". The best available
session mutex will be used for the synchronization; ideally, this will
be a mutex exposed by HttpSessionMutexListener.
The session mutex is guaranteed to be the same object during
the entire lifetime of the session, available under the key defined
by the SESSION_MUTEX_ATTRIBUTE
constant. It serves as a
safe reference to synchronize on for locking on the current session.
In many cases, the PortletSession reference itself is a safe mutex as well, since it will always be the same object reference for the same active logical session. However, this is not guaranteed across different servlet containers; the only 100% safe way is a session mutex.
handleActionRequestInternal(ActionRequest, ActionResponse)
,
HttpSessionMutexListener
,
org.springframework.web.portlet.util.PortletUtils#getSessionMutex(javax.portlet.PortletSession)
public final boolean isSynchronizeOnSession()
public final void setRenderWhenMinimized(boolean renderWhenMinimized)
javax.portlet.RenderRequest#getWindowState
,
javax.portlet.WindowState#MINIMIZED
public final boolean isRenderWhenMinimized()
public void handleActionRequest(ActionRequest request, ActionResponse response) throws java.lang.Exception
Controller
handleActionRequest
in interface Controller
request
- current portlet action requestresponse
- current portlet action responsejava.lang.Exception
- in case of errorspublic ModelAndView handleRenderRequest(RenderRequest request, RenderResponse response) throws java.lang.Exception
Controller
null
return value is not an error: It indicates that this
object completed request processing itself, thus there is no ModelAndView to render.handleRenderRequest
in interface Controller
request
- current portlet render requestresponse
- current portlet render responsejava.lang.Exception
- in case of errorsprotected void handleActionRequestInternal(ActionRequest request, ActionResponse response) throws java.lang.Exception
handleActionRequest
.
The default implementation throws a PortletException.
java.lang.Exception
handleActionRequest(ActionRequest, ActionResponse)
,
handleRenderRequestInternal(RenderRequest, RenderResponse)
protected ModelAndView handleRenderRequestInternal(RenderRequest request, RenderResponse response) throws java.lang.Exception
handleRenderRequest
.
The default implementation throws a PortletException.
java.lang.Exception
handleRenderRequest(RenderRequest, RenderResponse)
,
handleActionRequestInternal(ActionRequest, ActionResponse)