You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2004/03/03 01:10:35 UTC

DO NOT REPLY [Bug 27384] New: - Add support for other keys in saveMessages functions

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27384>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27384

Add support for other keys in saveMessages functions

           Summary: Add support for other keys in saveMessages functions
           Product: Struts
           Version: Nightly Build
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Standard Actions
        AssignedTo: struts-dev@jakarta.apache.org
        ReportedBy: gludington@knightridder.com


(See also Enhancement #28666, which requested a "Severity" attribute as a means
of grouping ActionMessages)

Sometimes it is helpful to group ActionMessages by a criterion other than just
the properties of an individual method.  For example, we might want to display
all form validation errors in one part of the page, and all business-layer or
system errors in another part of the page.  Since separate form validation
messages have different property names, it makes them unsuitable for grouping. 
The proper way to group these messges would be to save each class of messages
under different request or session-scoped attributes, and then call them using
(in the JSP world) the html:message tag and the name attribute.

However, the saveErrors() and saveMessages() functions in Action.java
specifically use the Globals.ERROR_KEY and Globals.MESSAGE_KEY, so if a
developer needs to save messages under another name, he/she has to do so
directly and implemeent the same null-out logic, if required.  The following
changes would make it easier for developers to save ActionMessages under
different keys.  There are two new methods:

saveMessages(HttpServletRequest request, ActionMessages messages, String
messageKeyName)
saveMessages(HttpSession session, ActionMessages messages, String messageKeyName)

The existing saveErrors and saveMessages functions invoke these new methods,
passing Globals.ERROR_KEY and Globals.MESSAGE_KEY, respectively, so there is no
change to existing functionality.

#26668 uses as an example four classes of messages that might be displayed on a
CRUD page -- form validation errors, confirmation needed, system errors, and
success messages.  With these new methods in Action.java, the Action could build
the different sets of messages, and save them something like the following:

saveErrors(request, errors) or saveMessages(request, errors, Globals.ERROR_KEY);
// validator already saves this
saveMessages(request, confirmationMessages, "CONFIRMATION_NEEDED");
saveMessages(request, systemErrors, "SYSTEM_ERRORS");
saveMessages(request, successMessages, "SUCCESS_MESSAGES");

saveMessages(request, messages, Globals.MESSAGE_KEY) could also be used, and
would work indentically to saveMessages(request, messages);

In the JSP, <html:errors/> and <html:messages/>...</html:messages> would behave
exactly as normally, but a page author can use the name attribute to distinguish
between the different sets of messages.  In the examples from #28666, it might be:

Form Errors:
<html:errors/> or <html:messages id="foo">...</html:messages>
Odd form data, please confirm:
<html:messages name="CONFIRMATION_NEEDED" id="foo">..</html:messages>
System Problems:
<html:messages name="SYSTEM_ERRORS" id="foo">..</html:messages>
Successful commit:
<html:messages name="SUCCESS_MESSAGES" id="foo">..</html:messages>

This would allow for groupings of messages in such a way that is already
compatible with the current set of functions and taglibs, and without having to
adjust any portions of the ActionMessage class itself.

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org