So, I had this originally:
<html:errors/> <html:errors bundle="EXCEPTION_MESSAGES"/>
The idea was that the top tag would present any form validation error messages, while the bottom tag would present any messages associated with exceptions that occur after validation has succeeded, such as an InvalidLoginException, or similar. The two bundles have different values for errors.header and errors.footer, so that the two types of feedback can be formatted differently.
But this did not work because the first tag was presenting its header and footer even though there were no form validation error messages, seemingly because there was an error message associated with the exception available as a request attribute. Shouldn't the html:errrors tag go a step further, and only render anything if there are messages *from the specified bundle* in scope, and not just any error message at all? I tried explicity declaring the default bundle in the first tag; it made no difference.
Anyway, I enumerated the request parameters present when a form validation error occurred, and those present when an exception occurred after form validation had succeeded. There was, Thank God because it's late, one difference: When an Exception is thrown, there is one additional request attribute under the key "org.apache.struts.action.EXCEPTION". That request attribute is not there when a form validation error has cut processing short.
So then I found the logic:present and logic:notPresent tags . . . . Now I have this:
<logic:present name="org.apache.struts.action.EXCEPTION"> <html:errors bundle="EXCEPTION_MESSAGES"/> </logic:present> <logic:notPresent name="org.apache.struts.action.EXCEPTION"> <html:errors/> </logic:notPresent>
Now, if a form validation error occurs, the top html:errors tag renders nothing (this works even without the logic:present tag, but I included it for goodness), and the bottom html:errors tag presents the form validation error messages, including header and footer, from the default bundle. If, on the other hand, an Exception occurs after form validation has succeeded, the top html:errors tag renders the exception message, with a different header and footer, and the bottom html:errors tag renders nothing (event though it so desperately WANTS to), because it has been foiled by the logic:notPresent tag.
Someone slap me. The ordeal seemingly is finished.
This also brings up another question: Is there any way to tell the Validator plugin to pull messages from some bundle other than the default bundle? Ultimately I want my solution to look like this:
<html:errors bundle="FORM_VALIDATION_ERROR_MESSAGES"/> <html:errors bundle="EXCEPTION_MESSAGES"/>
The top tag should only render if there are messages in scope *from the specified bundle*. Ditto for the second tag. This also would assume that the Validator plugin could be told to pull its messages from the FORM_VALIDATION_ERROR_MESSAGES properties file, instead of the default file.
Thanks and good night!
Erik
Erik Weber wrote:
Well, this didn't work, the header and footer from the default bundle are rendered even though there are no form validation errors, despite that the displayed error message is from the other bundle! Perhaps the errors.header and errors.footer are "inherited" from the default bundle if they are not defined in the secondary bundle?
Regardless, I am back to square one. I would appreciate any help.
Erik
Erik Weber wrote:
Seemingly a simple way to accomplish this would be to put the form validation error messages into one properties file, and to define errors.header and errors.footer for that file, and to put the non-form validation error messages into a different properties file, and to *not* define errors.header and errors.footer for that file. Then, in my JSP, I could put two html:errors tags in the error presentation area, each with a different bundle attribute:
<html:errors bundle="formValidationErrors"/> <html:errors bundle="nonFormValidationErrors"/>
The idea is that at most one of the two would ever actually render anything.
This is what I will try unless someone has a better ideer . . . . Sorry but I find the HTML tag documentation to be far from clear, despite how great the tags are. There is probably a better way, but I need a concrete example.
Erik
Erik Weber wrote:
I am using the Validator plugin to do my form validation, and so with the <html:errors/> tag placed at the top of my content area, the form validation messages are presented, with the header and footer defined by errors.header and errors.footer. In the traditional manner, the form validation output looks something like this:
Error
Please correct these errors:
* Username is required * Password2 must match Password1
Now, I am also presenting non-validation error messages in the same location on some pages; These are caused by Exceptions that are accounted for declaratively in struts-config.xml. The problem is, I don't want these messages to be presented with the header and footer (or maybe I want a different header and footer).
A concrete example:
For my login page, if you fail to enter a username or password, I want the error message presentation to look like the example above -- with a header and a footer (causing a table with a bulleted list to be rendered). But, if you enter the *wrong* password, and an AuthenticationException is thrown, the user ends up back at the same screen, except this time, I want the error message to be unadorned (or possibly with a different treatment), like this:
Authentication failed
As I said, AuthenticationException is handled declaratively. What is the easiest way to present the message associated with the exception *without* the header and footer in this case, while leaving the form validation error presentation (with header and footer) intact?
Thanks,
Erik
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
