RE: Unclear semantics on form use for wizards
Hi,
I actually had a similar problem with wanting to use Session scoped ActionForms and
not having them reset every time they were recycled by an Action.
The approach I took was to subclass ActionMapping to add a JavaBean property named
reset that can be set from the struts-config.xml and to subclass the RequestProcessor
and override processPopulate() to check for the value of my ActionMapping.getReset().
This makes it so I can choose whether or not reset the form-bean when a particular
Action is executed declaritive fashion from the struts-config.xml
The following are my code enhancements to attain this (I can fix them up a bit to
change the base ActionMapping and RequestProcessor and submit them as code
contributions to the project, if any of the committers think they are worthy):
ActionMapping (ClfyActionMapping) enchancements:
-
/**
* Flag used by AuthProcessor to determine if the form-bean for the Action
* should execute the form.reset() method before forwarding
*/
private boolean reset = true;
public void setReset(String reset) {
if (reset.equalsIgnoreCase(true)) {
this.reset = true;
}
if (reset.equalsIgnoreCase(false)) {
this.reset = false;
}
}
public boolean getReset() {
return this.reset;
}
RequestProcessor (AuthProcessor) enhancements:
-
/**
* Populate the properties of the specified ActionForm instance from
* the request parameters included with this request. Also checks
* the ActionMapping for the value of the reset flag to determine
* if the ActionForm should be reset before processing the ActionForward.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
* @param form The ActionForm instance we are populating
* @param mapping The ActionMapping we are using
*
* @exception ServletException if thrown by RequestUtils.populate()
*/
protected void processPopulate(HttpServletRequest request,
HttpServletResponse response,
ActionForm form,
ActionMapping mapping)
throws ServletException {
if (form == null) {
return;
}
// Recast ActionMapping to ClfyActionMapping and getReset()
boolean reset = true;
boolean bClfMapping = mapping instanceof ClfyActionMapping;
if (bClfMapping) {
ClfyActionMapping clfMapping = (ClfyActionMapping) mapping;
reset = clfMapping.getReset();
}
// Populate the bean properties of this ActionForm instance
if (log.isDebugEnabled()) {
log.debug( Populating bean properties from this request);
}
form.setServlet(this.servlet);
// Conditionally reset the ActionForm using reset in ClfyActionMapping
if (reset == true) {
form.reset(mapping, request);
}
if (mapping.getMultipartClass() != null) {
request.setAttribute(Action.MULTIPART_KEY,
mapping.getMultipartClass());
}
RequestUtils.populate(form, mapping.getPrefix(), mapping.getSuffix(),
request);
}
Jason Rosen
-Original Message-
From: Brian Topping [mailto:topping;digidemic.com]
Sent: Sunday, November 10, 2002 11:21 PM
To: [EMAIL PROTECTED]
Subject: Unclear semantics on form use for wizards
Greetings all,
I'm trying to get my head out of the sand with regard to use of
DynaActionForms whose contents persist across multiple action invocations. I
guess this is commonly called the wizard case. I'm hoping you guys can
shed some light on my damage WRT this issue (I'll manage the other damage
separately ;) My understanding is:
a) this should be possible and is encouraged
b) that doing so is enabled by setting the scope attribute on the action item
to 'session'
If these are true, I believe current source tree to be broken in this regard,
as I do not see a code path through RequestProcessor.processPopulate() that
does not call form.reset(), nor a path through DynaActionForm.reset() that
will leave the current values intact based on the scope of the form.
Having said that, how is it possible to create a form that can live across
Action invocations? Implementing a subclass of DynaActionForm with a custom
reset() would require some kind of external interlock to ensure that it could
be reset when we really truly did want it to be reset (like when the form was
created). Alternately to an interlock, the form could be completely disposed
at the end of a wizard sequence, forcing the framework to recreate it. In
that case, the constructor for the subclass would have to call
RE: Unclear semantics on form use for wizards
I forgot to include a snippet of my struts-config.xml to illustrate how to use the
code I posted:
struts-config.xml
-
action
path=/addcontact
type=com.mycompany.AddContactAction
name=contactInfo
scope=session
input=doc.contactForm
set-property
property=reset
value=false/
/action
Jason Rosen
-Original Message-
From: Jason Rosen
Sent: Monday, November 11, 2002 10:05 AM
To: Struts Developers List
Subject: RE: Unclear semantics on form use for wizards
Hi,
I actually had a similar problem with wanting to use Session scoped ActionForms and
not having them reset every time they were recycled by an Action.
The approach I took was to subclass ActionMapping to add a JavaBean property named
reset that can be set from the struts-config.xml and to subclass the RequestProcessor
and override processPopulate() to check for the value of my ActionMapping.getReset().
This makes it so I can choose whether or not reset the form-bean when a particular
Action is executed declaritive fashion from the struts-config.xml
The following are my code enhancements to attain this (I can fix them up a bit to
change the base ActionMapping and RequestProcessor and submit them as code
contributions to the project, if any of the committers think they are worthy):
ActionMapping (ClfyActionMapping) enchancements:
-
/**
* Flag used by AuthProcessor to determine if the form-bean for the Action
* should execute the form.reset() method before forwarding
*/
private boolean reset = true;
public void setReset(String reset) {
if (reset.equalsIgnoreCase(true)) {
this.reset = true;
}
if (reset.equalsIgnoreCase(false)) {
this.reset = false;
}
}
public boolean getReset() {
return this.reset;
}
RequestProcessor (AuthProcessor) enhancements:
-
/**
* Populate the properties of the specified ActionForm instance from
* the request parameters included with this request. Also checks
* the ActionMapping for the value of the reset flag to determine
* if the ActionForm should be reset before processing the ActionForward.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
* @param form The ActionForm instance we are populating
* @param mapping The ActionMapping we are using
*
* @exception ServletException if thrown by RequestUtils.populate()
*/
protected void processPopulate(HttpServletRequest request,
HttpServletResponse response,
ActionForm form,
ActionMapping mapping)
throws ServletException {
if (form == null) {
return;
}
// Recast ActionMapping to ClfyActionMapping and getReset()
boolean reset = true;
boolean bClfMapping = mapping instanceof ClfyActionMapping;
if (bClfMapping) {
ClfyActionMapping clfMapping = (ClfyActionMapping) mapping;
reset = clfMapping.getReset();
}
// Populate the bean properties of this ActionForm instance
if (log.isDebugEnabled()) {
log.debug( Populating bean properties from this request);
}
form.setServlet(this.servlet);
// Conditionally reset the ActionForm using reset in ClfyActionMapping
if (reset == true) {
form.reset(mapping, request);
}
if (mapping.getMultipartClass() != null) {
request.setAttribute(Action.MULTIPART_KEY,
mapping.getMultipartClass());
}
RequestUtils.populate(form, mapping.getPrefix(), mapping.getSuffix(),
request);
}
Jason Rosen
-Original Message-
From: Brian Topping [mailto:topping;digidemic.com]
Sent: Sunday, November 10, 2002 11:21 PM
To: [EMAIL PROTECTED]
Subject: Unclear semantics on form use for wizards
Greetings all,
I'm trying to get my head out of the sand with regard to use of
DynaActionForms whose contents persist across multiple action invocations. I
guess this is commonly called the wizard case. I'm hoping you guys can
shed some light on my damage WRT this issue (I'll manage the other damage
separately ;) My understanding is:
a) this should be possible and is encouraged
b) that doing so is enabled by setting the scope attribute on the action item
to 'session'
If these are true, I believe current source tree to be broken in this regard,
as I do not see a code path through RequestProcessor.processPopulate() that
does not call form.reset(), nor a path
RE: Unclear semantics on form use for wizards
Craig, That's true, I could have subclassed DynaValidatorForm and modified the reset() method to accomodate my needs. Originally, I had taken that route, but then found myself with many ActionForm subclasses to accomodate all sorts of scenarios - I had subclasses of DynaActionForm, DynaValidatorForm, and ActionForm, just to turn off reset(). I found that by centralizing the reset switch and being able to declare it in the struts-config.xml made my code and config files much cleaner, re-usable, and easier to maintain. I also figured that if the validate() hotspot could be turned on and off from the struts-config.xml, why not reset()? Jason Rosen -Original Message- From: Craig R. McClanahan [mailto:craigmcc;apache.org] Sent: Monday, November 11, 2002 11:04 AM To: Struts Developers List Subject: RE: Unclear semantics on form use for wizards On Mon, 11 Nov 2002, Jason Rosen wrote: Date: Mon, 11 Nov 2002 10:04:42 -0800 From: Jason Rosen [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: Unclear semantics on form use for wizards Hi, I actually had a similar problem with wanting to use Session scoped ActionForms and not having them reset every time they were recycled by an Action. An alternative strategy is to make the reset() method of your form beans smarter about which page of a multi-page wizard this submit is for (easy to determine because reset() has access to the request). Craig -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Unclear semantics on form use for wizards
Hmmm... I'll have to look into how reset() impacts unchecked checkboxes - I haven't had to deal with too many checkboxes in my project. Thanks for raising some issues to make me think about it, Craig. Jason -Original Message- From: Craig R. McClanahan [mailto:craigmcc;apache.org] Sent: Monday, November 11, 2002 11:21 AM To: Struts Developers List Subject: RE: Unclear semantics on form use for wizards On Mon, 11 Nov 2002, Jason Rosen wrote: Date: Mon, 11 Nov 2002 11:11:41 -0800 From: Jason Rosen [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: Unclear semantics on form use for wizards Craig, That's true, I could have subclassed DynaValidatorForm and modified the reset() method to accomodate my needs. Originally, I had taken that route, but then found myself with many ActionForm subclasses to accomodate all sorts of scenarios - I had subclasses of DynaActionForm, DynaValidatorForm, and ActionForm, just to turn off reset(). I found that by centralizing the reset switch and being able to declare it in the struts-config.xml made my code and config files much cleaner, re-usable, and easier to maintain. I also figured that if the validate() hotspot could be turned on and off from the struts-config.xml, why not reset()? I think allowing reset() to be turned off completely would be confusing and error prone for anyone using a boolean form bean property, because an unchecked checkbox would no longer work as expected. Jason Rosen Craig -Original Message- From: Craig R. McClanahan [mailto:craigmcc;apache.org] Sent: Monday, November 11, 2002 11:04 AM To: Struts Developers List Subject: RE: Unclear semantics on form use for wizards On Mon, 11 Nov 2002, Jason Rosen wrote: Date: Mon, 11 Nov 2002 10:04:42 -0800 From: Jason Rosen [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: Unclear semantics on form use for wizards Hi, I actually had a similar problem with wanting to use Session scoped ActionForms and not having them reset every time they were recycled by an Action. An alternative strategy is to make the reset() method of your form beans smarter about which page of a multi-page wizard this submit is for (easy to determine because reset() has access to the request). Craig -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Unclear semantics on form use for wizards
The reset() method lives in the ActionForm class. In order to have reset() evaluate what to do means overriding reset() by subclassing ActionForm (or some child of ActionForm). So to have all these different reset() evaluations means having different ActionForm subclasses. Then if you wanted to use a different ActionForm implementation like DynaActionForm or DynaValidatorForm, you start duplicating your reset() code around because Java doesn't allow for multiple inheritance. This is the mess I started finding myself in - some of my Actions were using DynaActionForms, some were using DyanValidatorForms, and some were ActionForms but I needed similar reset() functionality in all of them. So the reset() code was getting hard to maintain. I thought it might be better to evaluate when to reset more in the Controller layer (I chose the RequestProcessor) rather than the input-view layer (ActionForm). As Craig pointed out, I may not have done a full evaluation of the consequences of my modifications regarding turning off reset() all together. Jason -Original Message- From: edgar [mailto:edgar;blue-moose.net] Sent: Monday, November 11, 2002 11:56 AM To: 'Struts Developers List' Subject: RE: Unclear semantics on form use for wizards Isn't a better way of handling this to keep awareness of the action in progress (in reset and validate you can just look at the request), and make a decision as to what reset action to take rather than creating new classes. Hope that helps. Edgar -Original Message- From: Jason Rosen [mailto:JRosen;yvimail.com] Sent: Monday, November 11, 2002 2:26 PM To: Struts Developers List Subject: RE: Unclear semantics on form use for wizards Hmmm... I'll have to look into how reset() impacts unchecked checkboxes - I haven't had to deal with too many checkboxes in my project. Thanks for raising some issues to make me think about it, Craig. Jason -Original Message- From: Craig R. McClanahan [mailto:craigmcc;apache.org] Sent: Monday, November 11, 2002 11:21 AM To: Struts Developers List Subject: RE: Unclear semantics on form use for wizards On Mon, 11 Nov 2002, Jason Rosen wrote: Date: Mon, 11 Nov 2002 11:11:41 -0800 From: Jason Rosen [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: Unclear semantics on form use for wizards Craig, That's true, I could have subclassed DynaValidatorForm and modified the reset() method to accomodate my needs. Originally, I had taken that route, but then found myself with many ActionForm subclasses to accomodate all sorts of scenarios - I had subclasses of DynaActionForm, DynaValidatorForm, and ActionForm, just to turn off reset(). I found that by centralizing the reset switch and being able to declare it in the struts-config.xml made my code and config files much cleaner, re-usable, and easier to maintain. I also figured that if the validate() hotspot could be turned on and off from the struts-config.xml, why not reset()? I think allowing reset() to be turned off completely would be confusing and error prone for anyone using a boolean form bean property, because an unchecked checkbox would no longer work as expected. Jason Rosen Craig -Original Message- From: Craig R. McClanahan [mailto:craigmcc;apache.org] Sent: Monday, November 11, 2002 11:04 AM To: Struts Developers List Subject: RE: Unclear semantics on form use for wizards On Mon, 11 Nov 2002, Jason Rosen wrote: Date: Mon, 11 Nov 2002 10:04:42 -0800 From: Jason Rosen [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: Unclear semantics on form use for wizards Hi, I actually had a similar problem with wanting to use Session scoped ActionForms and not having them reset every time they were recycled by an Action. An alternative strategy is to make the reset() method of your form beans smarter about which page of a multi-page wizard this submit is for (easy to determine because reset() has access to the request). Craig -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail
