Just to clarify for archive searchers.
The <logic:messagesPresent> and <html:messages> work with declarative
programming. These tags were introduced to provide the programmer more
control over the formatting of the messages, compared to what <html:errors>
provide. For example, <html:errors> require HTML tags to be present in the
message itself in the application resources file. With logic:messagesPresent
and html:messages, all the actual formatting can be done on the JSP. The
example I showed was written just to illustrate the difference between the
regular "validation errors" as opposed to non-validation errors which one
might want to format differently.
--- Erik Weber <[EMAIL PROTECTED]> wrote:
> 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 programming!
>
> Perhaps people will have opinions on these two ways of solving the same
> problem.
>
> Erik
>
>
> Hubert Rabago wrote:
>
> >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);
> >
> >
> >For other messages you want special formatting, save it in a different
> >request attribute, say "autherrors":
> >
> >// special error
> >ActionMessages actionMessages = new ActionMessages();
> >actionMessages.add(ActionMessages.GLOBAL_MESSAGE,
> > new ActionMessage("auth.failed", someOptionalParam));
> >request.setAttribute("autherrors", actionMessages);
> >
> >The attribute name "autherrors" is what you'll use to render it
> differently.
> >
> >Now, in your JSP, use the <html:messages> tag to display all the messages
> >under the "autherrors" request attribute. If you want to add special
> headers
> >and footers, use the <logic:messagesPresent> to make sure they don't get
> >shown when there are no messages.
> >
> ><logic:messagesPresent name="autherrors">
> > Authentication error:<br/>
> > <html:messages name="autherrors" id="message">
> > <b><bean:write name="message"/></b><br/>
> > </html:messages>
> ></logic:messagesPresent>
> >
> >hth,
> >Hubert
> >
> >--- Erik Weber <[EMAIL PROTECTED]> 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]
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >__________________________________
> >Do you Yahoo!?
> >New and Improved Yahoo! Mail - Send 10MB messages!
> >http://promotions.yahoo.com/new_mail
> >
> >---------------------------------------------------------------------
> >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]
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
