[jira] Updated: (STR-2004) Add support for other keys in saveMessages functions

["Paul Benedict (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/struts/browse/STR-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Benedict updated STR-2004:
-------------------------------

    Fix Version/s: 1.4.0
         Assignee:     (was: Struts Developers)

> Add support for other keys in saveMessages functions
> ----------------------------------------------------
>
>                 Key: STR-2004
>                 URL: https://issues.apache.org/struts/browse/STR-2004
>             Project: Struts 1
>          Issue Type: Improvement
>          Components: Extras
>    Affects Versions: Nightly Build
>         Environment: Operating System: other
> Platform: Other
>            Reporter: Greg Ludington
>            Priority: Minor
>             Fix For: 1.4.0
>
>         Attachments: ActionDiffs.txt
>
>
> (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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.