Just to clarify for archive searchers.
The and work with declarative
programming. These tags were introduced to provide the programmer more
control over the formatting of the messages, compared to what
provide. For example, require HTML tags to be present in the
message itself in the applica
Thanks Hubert. If you see my last post, you'll see that I solved the
problem without having to write any Java code -- I did it all
declaratively and with tags. Nowhere in my code do I create
ActionMessages instances -- I am trying to let Struts do this for me,
and stick with declarative program
OK I solved the problem. The problem was that the html:errors tag that
is pulling messages from the default bundle apparently renders
errors.header and error.footer if *any* error message is stored as a
request attribute, no matter what bundle that error message might come
from. This seems wron
For validation errors, do the usual, using the saveErrors to pass them to the
JSP:
// validation error
ActionMessages actionMessages = new ActionMessages();
actionMessages.add(ActionMessages.GLOBAL_MESSAGE,
new ActionMessage("illegal.username", username));
saveErrors(request, actionMessages)
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
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.head
6 matches
Mail list logo
