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 the superclass
reset() in order to read in the initial values from the <form-property>
elements. This seems counter-intuitive and I'm guessing just an oversight,
given the power provided by <form-property> elements.
If in fact my head is threaded correctly and screwed on tight, it would seem
that the fix would be to move the call to processPopulate() at
RequestProcessor.java:251 to a new line after line 369, thereby only calling
reset() if the form was being used in request scope.
There are a number of open and unanswered threads about this on struts-user,
making it a documentation error or a coding error. While the source is the
ultimate form of documentation, there are many in the field that use Struts
in commercial environments such as BEA and IBM and are not used to finding
the answer this way. While I am quite jazzed to get a copy of Chuck's book
in my hands so I can read something that doesn't flicker at 70Hz, I dearly
wish that the JavaDocs sufficiently covered the topics so that the reigning
king of IDEs (IntelliJ IDEA, of course :-) could beam clarity into my feeble
pea of a brain with the expended effort of typing "shift-F1".
I'll prepare a patch if required, either for the source or the docs, but I
wasn't ready to presume that I was in sync with ppl on this.
Thanks for bearing with me...
-b
--
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>
