----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 16, 2002 12:14 PM Subject: Retrieving messages from the default and non-default bundles
I'm posting this question to the dev group, because I'm not that many are using the multiple bundle support of 1.1 yet. I've noticed that several of the methods for getting access to the Servlet and thus the ServletContext have been removed from classes like ApplicationConfig. This has made it a little harder to get messages from the message bundles. The RequestUtils.selectApplication() method stores the default MessageResources into the request, but what approach should be used to get a message from the bundle from someplace other than a JSP? Should we recommend that developers get the default MessageResources from the request and use that, or are there better alternatives? What about when you're using multiple resource bundles for an application, and you need a message from one of the non-default bundles? It appears that only the default MessageResources is being stored in the request. The addition of multiple bundles is a great new feature, but appears to be a little cumbersome to get access to the messages. Especially since a few of the strategic getServlet() methods have been removed. Here's an example for context. Suppose that you want to extend the ExceptionHandler and get some other values from one of the bundles, in addition to the key that is configured with the exception mapping. How can this be done within the ExceptionHandler for example? Should there be a utility method in the RequestUtils for this? The ones that are there now are tied to the JSP due to the PageContext. If anyone can shed a little light on this, I would appreciate it. Chuck There are some *hidden rules* I discovered while I am finishing up my struts visual module. Developers should not consult to classes with their name ending with 'Config' for servlet (servlet context). Those classes play a role of organizers and the servlet instance is available in form bean and action classes. Since I buy this rule, Craig's decision to remove getServlet() is easy to understand for me. Another rule is to use request scoped ActionErrors/ActionMessages as much as possible (for better scalability than 1.0?) Once I am in ExceptionHandler or Validator or Action classes, I am in business to create possible ActionErrors/ActionMessages and those messages, if any, will be consumed by the Errors/Messages tag in the next JSP page. The scope property in ExceptionHandler looks to me is a little redundant or inconsistent if I buy this rule. I am not very clear what other values you want to get from one of the bundles, if you mean the arguments to the ActionErrors/ActionMessages when you build them, you could take a look at StrutValidatorUtil. However Strut's validator APIs are not organized as flexible as rest of the framework when handling multiple bundles. I could not find any easy way to have the validator to use MessageResources other than the default one. If anyone finds an easy way, please point it out. I would appreciate it. Jing -- Posted via jApache.org -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
