Of course, applications can define other result tokens to match specific cases.
null) from an Action class method causes the results processing to be skipped. This is useful if the action fully handles the result processing such as writing directly to the HttpServletResponse OutputStream.
The result element has two jobs. First, it provides a logical name. An
Action can pass back a token like "success" or "error" without knowing any other implementation details. Second, the result element provides a result type. Most results simply forward to a server page or template, but other Result Types can be used to do more interesting things.
<action name="Hello"> <result>/hello/Result.jsp</result> <result name="error">/hello/Error.jsp</result> <result name="input">/hello/Input.jsp</result> </action>
A special 'other' result can be configured by adding a result with name="*". This result will only be selected if no result is found with a matching name.
<action name="Hello"> <result>/hello/Result.jsp</result> <result name="error">/hello/Error.jsp</result> <result name="input">/hello/Input.jsp</result> <result name="*">/hello/Other.jsp</result> </action>
The name="*" is not a wildcard pattern, it is a special name that is only selected if an exact match is not found.
In most cases if an action returns an unrecognized result name this would be a programming error and should be fixed.
Most often, results are nested with the action element. But some results apply to multiple actions. In a secure application, a client might try to access a page without being authorized, and many actions may need access to a "logon" result.
FragmentAction method returns "next" the actual value of that result will be whatever is in
nextAction property. So
nextAction may be computed based on whatever state information necessary then passed at runtime to "next"'s
See Parameters in configuration results for an expanded discussion.