On 1/30/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > >From: [EMAIL PROTECTED] > > > > Author: craigmcc > > Date: Mon Jan 30 15:49:55 2006 > > New Revision: 373633 > > > > URL: http://svn.apache.org/viewcvs?rev=373633&view=rev > > Log: > > Improve usability of the LoadBundle and Messages helper classes, by > explicitly > > loading the default resource bundle if the requested one is not found. > This > > needs to be reviewed to see if we should also do the "strip suffixes" > trick > > that ResourceBundle itself does (but only after explicitly finding a > bundle > > with the specified name, which is not particularly friendly). > > > > Also, customize the Shale property resolver so that expressions like: > > > > #{myLoadBundle['message.key']} > > > > work instead of (actually, for backwards compatibility, in addition to): > > > > #{myLoadBundle.map['message.key']} > > > > In this way, you can directly substitute use of the LoadBundle helper > class, > > which makes the resources available to Java event handlers as well, by > > simply removing all tags from your JSP pages, and creating > > a managed bean (typically in application scope) for the corresponding > > "var" name. > > > > That seems like a better approach. I also noticed that this class uses > the view root's locale object. It seems that this is problematic when used > with the tiger @value annotation on a managed bean. I think this was because > the view root or the context didn't exist yet. I didn't take to them to find > the cause of the null pointer exception. > > > @Value ("#{bundle.map}"); > Map messages = null;
I presume "bundle" is a managed bean that is (or extends) LoadBundle, right? This is probably not the best approach now the LoadBundle implements map. I > just wanted to comment on this one. You won't be able to succesfully evaluate an expression like this outside the context of a JSF request, because of the requirement that it use the request's locale to choose which message to return. If it is throwing NPE, then that should be refined to something more intelligent (probably IllegalStateException with a user-friendly error message explaining what happened). But this is definitely an error condition *unless* you are inside a Faces request. The new tiger library is really nice. It's going to be hard going back to > using the XML declarations :-) Yep :-). I'm working on a small example for my TSSJS session about web frameworks, which will have zero entries inside faces-config.xml :-). Gary > Craig
