[ 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.