[jira] Updated: (STR-1916) Cannot retrieve all MessageResources messages

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

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

Paul Benedict updated STR-1916:
-------------------------------

    Fix Version/s: Future

> Cannot retrieve all MessageResources messages
> ---------------------------------------------
>
>                 Key: STR-1916
>                 URL: https://issues.apache.org/struts/browse/STR-1916
>             Project: Struts 1
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.1.0
>         Environment: Operating System: Windows XP
> Platform: PC
>            Reporter: Jay Zylstra
>            Priority: Minor
>             Fix For: Future
>
>         Attachments: CedarMessageResources.java
>
>
> I'm developing an app that is localized into various European languages.  I've 
> used Struts' support for multiple resource bundles by creating topical bundles, 
> such as one of country names keyed by their ISO-3166 codes, and so forth, as 
> well as a default bundle of general messages.  I intend to use these topical 
> resource bundles to populate localized form drop-downs, but MessageResources 
> doesn't have any public methods nor fields to access all messages without first 
> knowing their keys.
> To solve this, I suggest a pair of methods like...
>   public java.lang.String[] getMessages();
>   public java.lang.String[] getMessages(java.util.Locale locale);
> ...to access all of the messages in a bundle.  Since I would also need to know 
> the messages' keys, I further suggest another method like...
>   public java.lang.String[] getKeys();
> ...which would also allow the use of parametric replacement when traversing a 
> bundle by passing each key into an existing getMessage() method.
> The benefit of returning String arrays is that they are immutable, protecting 
> the underlying resource bundle from corruption.  Alternately, an Iterator 
> implementation that ignores remove() could be returned, since remove() is 
> optional.  Because PropertyMessageResouces (MessageResources' concrete 
> subclass) is backed by a Map, neither approach should be very difficult.
> Finally, and this is probably beyond the scope of this suggestion, I need the 
> messages (not the keys) to be in alphabetical order, which would be quite 
> difficult using my suggested enhancement.  So, I'll probably have to subclass 
> PropertyMessageResources after all, but I thought I'd suggest this as an 
> enhancement anyhow, since others would obviously benefit from the 
> functionality.  Of course, I could manually sort the actual message bundle 
> contents, but that isn't nearly as elegant and is prone to error.
> JayZ

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