public class MockAction extends java.lang.Object implements Action
AbstractExternalizedFlowExecutionTests. If you are using a XML-based flow definition with a flow-local context to host your actions, consider overriding
AbstractXmlFlowExecutionTeststo install mock instances.
|Constructor and Description|
Constructs a new mock action that returns the default
Constructs a new mock action that returns the provided execution result.
|Modifier and Type||Method and Description|
Execute this action.
Sets attributes to associate with a returned action execution outcome.
Sets the event identifier this mock action will use as its execution outcome.
public MockAction(java.lang.String resultEventId)
resultEventId- the execution result identifier that will be returned
public void setResultEventId(java.lang.String resultEventId)
resultEventId- the action execution result identifier
public void setResultAttributes(AttributeMap<java.lang.Object> resultAttributes)
resultAttributes- the action execution result attributes
public Event execute(RequestContext context)
Action invocation is typically triggered in a production environment by a state within a flow carrying out the execution of a flow definition. The result of action execution, a logical outcome event, can be used as grounds for a transition out of the calling state.
RequestContext argument to this method provides access to data about the active flow execution
in the context of the currently executing thread. Among other things, this allows this action to access
data set by other actions, as well as set its own attributes it wishes
to expose in a given scope.
Some notes about actions and their usage of the attribute scope types:
request scopeexist for the life of the currently executing request only.
flash scopeexist until the next external user event is signaled. That time includes the current request plus any redirect or additional refreshes to the next view.
flow scopeexist for the life of the flow session and will be cleaned up automatically when the flow session ends.
conversation scopeexist for the life of the entire flow execution representing a single logical "conversation" with a user.
All attributes present in any scope are typically exposed in a model for access by a view when an "interactive" state type such as a view state is entered.
Note: flow scope should generally not be used as a general purpose cache, but rather as a context for data needed locally by other states of the flow this action participates in. For example, it would be inappropriate to stuff large collections of objects (like those returned to support a search results view) into flow scope. Instead, put such result collections in request scope, and ensure you execute this action again each time you wish to view those results. 2nd level caches managed outside of SWF are more general cache solutions.
Note: as flow scoped attributes are eligible for serialization they should be
context- the action execution context, for accessing and setting data in a
scope type, as well as obtaining other flow contextual information (e.g. request context attributes and flow execution context information)