| java.lang.Object org.apache.struts.chain.commands.ActionCommandBase org.apache.struts.chain.commands.AbstractPopulateActionForm
All known Subclasses: org.apache.struts.chain.commands.servlet.PopulateActionForm,
AbstractPopulateActionForm | abstract public class AbstractPopulateActionForm extends ActionCommandBase (Code) | | Populate the form bean (if any) for this request.
version: $Rev: 471754 $ $Date: 2005-11-12 13:01:44 -0500 (Sat, 12 Nov 2005) version: $ |
Method Summary | |
public boolean | execute(ActionContext actionCtx) | protected void | handleCancel(ActionContext context, ActionConfig actionConfig, ActionForm actionForm) Take into account whether the request includes any defined value for
the global "cancel" parameter. An issue was raised (but I don't
think a Bugzilla ticket created) about the security implications of
using a well-known cancel property which skips form validation, as you
may not write your actions to deal with the cancellation case. | abstract protected void | populate(ActionContext context, ActionConfig actionConfig, ActionForm actionForm) Populate the given ActionForm with request parameter
values, taking into account any prefix/suffix values configured on the
given ActionConfig . | abstract protected void | reset(ActionContext context, ActionConfig actionConfig, ActionForm actionForm) | protected String | trimParameterName(ActionConfig actionConfig, String name) For a given request parameter name, trim off any prefix and/or
suffix which are defined in actionConfig and return what
remains. |
execute | public boolean execute(ActionContext actionCtx) throws Exception(Code) | | Populate the form bean (if any) for this request.
Parameters: actionCtx - The Context for the current request false so that processing continues throws: Exception - On an unexpected error |
handleCancel | protected void handleCancel(ActionContext context, ActionConfig actionConfig, ActionForm actionForm) throws Exception(Code) | | Take into account whether the request includes any defined value for
the global "cancel" parameter. An issue was raised (but I don't
think a Bugzilla ticket created) about the security implications of
using a well-known cancel property which skips form validation, as you
may not write your actions to deal with the cancellation case.
Parameters: context - The ActionContext we are processing Parameters: actionConfig - The ActionConfig we are processing Parameters: actionForm - The ActionForm we are processing throws: Exception - On an unexpected error See Also: Globals.CANCEL_PROPERTY See Also: Globals.CANCEL_PROPERTY_X |
populate | abstract protected void populate(ActionContext context, ActionConfig actionConfig, ActionForm actionForm) throws Exception(Code) | | Populate the given ActionForm with request parameter
values, taking into account any prefix/suffix values configured on the
given ActionConfig .
Parameters: context - The ActionContext we are processing Parameters: actionConfig - The ActionConfig we are processing Parameters: actionForm - The ActionForm we are processing throws: Exception - On an unexpected error |
reset | abstract protected void reset(ActionContext context, ActionConfig actionConfig, ActionForm actionForm)(Code) | | Call the reset() method on the specified form
bean.
Parameters: context - The context for this request Parameters: actionConfig - The actionConfig for this request Parameters: actionForm - The form bean for this request |
trimParameterName | protected String trimParameterName(ActionConfig actionConfig, String name)(Code) | | For a given request parameter name, trim off any prefix and/or
suffix which are defined in actionConfig and return what
remains. If either prefix or suffix is defined, then return null for
name values which do not begin or end accordingly.
Parameters: actionConfig - The ActionConfig we are processing Parameters: name - The request parameter name to proceess The request parameter name trimmed of any suffix or prefix |
|
|