Craig McClanahan wrote:
On 2/21/06, Richard Wallace <[EMAIL PROTECTED]> wrote:
Craig McClanahan wrote:
On 2/21/06, Richard Wallace <[EMAIL PROTECTED]> wrote:
Hello everyone,
I have a simple feature request. Can we get a method added to the
AbstractViewController class that gets a message out of the
applications
configured message bundle? Something as simple as:
protected String getMessage (String messageKey) {
ResourceBundle rb = ResourceBundle.getBundle (getApplication
().getMessageBundle (), getFacesContext ().getViewRoot ().getLocale
());
return rb.getString (messageKey);
}
Something that might also be useful is one that takes an optional
Object[] as parameters and then uses MessageFormat to format the
message:
protected String getMessage (String messageKey, Object[] params) {
String messageBundleName = getApplication ().getMessageBundle
();
Locale locale = getFacesContext ().getViewRoot ().getLocale ();
ResourceBundle rb = ResourceBundle.getBundle(messageBundleName,
locale);
String msgPattern = rb.getString (messageKey);
String message;
if (params != null) {
message = MessageFormat.format (msgPattern, params);
} else {
message = msgPattern;
}
return message;
}
I've found this to be of tremendous help in simplifying error handling
code, or when I want to display a success message or something like
that. It makes things so much cleaner.
You can do something similar in spirit to this with the existing
org.apache.shale.util.Messages class. The javadocs describe how to
define
an application scope managed bean, configured for a particuar resource
bundle. Let's say you stored this under managed bean name
"messages". Now,
you can generate formatted messages with it:
Messages messages = (Messages) getBean("messages");
Locale locale = context.getViewRoot().getLocale();
String localizedMessage = messages.getMessage("message.key",
locale, new Object[] { ... parameters ... });
Is that close enough to what you are after?
I didn't realize there was a component that already wrapped the message
formatting and all, that is pretty cool. But it's not exactly what I
was looking for. I'm looking for something dead simple with minimal
extra lines of code. I'm always forgetting what params I need to create
the message bundle and where to look them up from. I always find myself
just copying the same bits of code from one place to another. So I just
want something that would give me a one-liner that I have to remember to
get the message I need.
Before I started using Shale and the AbstractViewController I had an
abstract class that all my backing beans extended that simply provided
these kinds of ease of use methods. The only one that I've found
missing in the AbstractViewController is this getMessage() method. If
nothing else I'll just change by abstract class to extend the
AbstractViewController and just add the getMessage() methods, but I
thought others might find it useful as well so thought I'd bring it up.
I like the basic idea ... the challenge is finding the right balance between
simplicity and flexibility when you add helper methods like this. For
example, your code looks up the message bundle defined in
faces-config.xml(yay simplicity!), but doesn't let me use more than
one resource bundle (boo
flexibiolity!).
:-)
That's the problem with trying to define any API though, isn't it?
Trying to find the right balance of simplicity and flexibility. From
the books I've read on JSF it seems that users are expected to define
their error and other messages in a bundle and tell the web application
about it using faces-config.xml. That's been my interpretation at
least, and seems to be the way most other people lean.
So, I'm not sure flexibility is a big concern. That being said, I
wouldn't be entirely opposed to another form for the method, that being
getMessage (String messageKey, String messageBundle). Of course, that
does add some concern of an increasingly complex interface, but that
always seems to happen when you add flexibility.
Rich
Craig
What do you think?
Thanks,
Rich
Craig
---------------------------------------------------------------------
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]
