Erik,
I just tried an example of what you are saying (triggering a declarative exception and then losing the token in the redisplayed form) and I did not lose the token! Here is the action mapping I am using:
<action path="/Login"
type="com.oreilly.strutsckbk.ch09.LoginAction"
scope="request"
name="LoginForm"
validate="true"
input="/login.jsp">
<exception key="error.password.match"type="com.oreilly.strutsckbk.ch09.PasswordMatchException"/>
<forward name="success" path="/login_success.jsp" redirect="true"/>
</action>The only reason I would think that the token would be lost would be if you redirected instead of forwarded to the input page.
Bill Siggelkow
Erik Weber wrote:
Susan, I could not use your option, but it did lead me to a solution. I would like to know if anyone has a better solution, since mine involves catching and rethrowing an Exception, which is, however small, a performance hit to take. Also, it kind of defeats the purpose of Struts' declarative Exception handling. I have a specific question for those who might be more familiar with Struts code (I have successfully avoided fooling with the source code so far).
Since my "validation" error is really an Exception that is thrown by a manager layer object and that is handled by the Struts Exception handler according to what is configured in struts-config.xml, I didn't have a place to invoke saveToken if one of these Exceptions was thrown, because my Action was not catching the Exception -- Struts' Exception handler was.
So I put in a try-catch block in my Action code around the invocations to the manager layer objects. If one of these "validation" Exceptions is thrown, I catch it and simply rethrow it -- but this gives me a place to insert a saveToken invocation before I rethrow the Exception. It's not ideal, but it's simple at least.
What I really would like is, to mimic what Action.saveToken does, within the execute method of an ExceptionHandler extension, whenever one of these types of Exceptions is handled. Then I don't have to catch and rethrow. Will this work? It might depend on what exactly Action.saveToken is doing (and how the token hidden parameter ends up being rendered in the form) I guess, since the invocation of saveToken would occur in a different chronological place (ExceptionHandler.execute) from where it occurs in my current solution (Action.execute).
Or is there a better idea still?
Thanks, Erik
Susan Bradeen wrote:
Erik Weber <[EMAIL PROTECTED]> wrote on 08/25/2004 09:03:18 AM:
I am using saveToken, isTokenValid, etc., to ensure that a registration/update form is not stale. I invoke this method from execute
in the setup Action, just before forwarding to the form page.
When the form is submitted, there are two levels of validation before the form data is processed.
First, input validation happens. I use ValidatorForm with the Validator plugin. If there is an input validation error, Struts forwards back to the input page, and the original synchronizer token is still in place as
a hidden variable in the form.
Second, if input validation succeeds, there is validation at the manager
layer. For example, a username might already be taken. If there is a manager validation error, Struts forwards back to the input page, but this time, the synchronizer token is not in place -- the hidden field in
the form is gone.
Erik, You are probably doing validation differently, but maybe this will spur some ideas. I called the validate from the 'save' Action, and passed the token with the request again after it failed validation:
if (!isCancelled(request)) {
// Validate form parameters ... ActionErrors validErrors = reqForm.validate(mapping, request);
if (validErrors != null && !validErrors.isEmpty()) {
saveErrors(request, validErrors);
saveToken(request);
return new ActionForward(mapping.getInput());
}// end validate
...}
HTH,
Susan Bradeen
The result of this is that if you request an add/edit form, fill it out,
submit it and cause a manager validation error, you cannot simply edit the offending field and resubmit the form -- you need a fresh form. This
is not the desired behavior, as this type of validation error should be treated the same as a form validation error, with regard to the synchronizer token.
I am using Struts declarative exception handling, which handles the forwarding.
How can I make sure the hidden field is rendered in the form after the second type of error occurs and Struts forwards back to the input screen? Why is it gone in the first place? I thought of RequestProcessor.processException, but couldn't see a way to invoke resetToken or saveToken. Should I do something with my form bean reset method?
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs. _____________________________________________________________________________
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
