Basically I agreed with your concerns and felt that we are probably probing the same problem, but from very different perspectives.
Suppose I am in ExceptionHandler.execute() method, I would like to access non-default bundles from here. So I need to get the action servlet instance and then its context. The *real* problem is that I am not guaranteed to get the action servlet instance from the API's formInstance, because it might be null at runtime! Even there is a RequestUtils utility method, it will not help me here. In my own world, I have four classes BasicFormController (extends Action), BasicFormValidator (understands my UI), BasicExceptionHandler (extends ExceptionHandler), and another one (related to UI) I think the four belong to ONE category: They all handle certain business logic but with different area and at different times. Since we all understand the semantic of Action class, it is recycled, shared by multiple threads. Why not my BasicFormValidator, BasicExceptionHandler? If there is no very very negative side effect, they should be so. Therefore, I got a consistent and united view: They all have the getServlet() and setServlet() methods, and my RequestProcessor will assign the action servlet instance to them after creation. The BasicFormValidator will accept a parameter 'Theme' from UI which includes user specified bundle if any. But I feel hard to take advantage of the Struts validator regarding to the bundle. Suppose you could get the action servlet instance in the ExceptionHandler base class, will that resolve most of your concerns in 2)? Jing ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Friday, May 17, 2002 10:27 AM Subject: Re: Retrieving messages from the default and non-default bundles > Jing, > > The issue that I was raising is a little different, > although somewhat related. There are two issues that I > was specifically looking for an answer to. > > 1) Even though the getServlet() method is present in the > ActionForm and Action classes, it's still cumbersome to > retrieve the messages from a bundle other than the > default. The only way that I see is to get the Servlet, > and then the ServletContext, and then get the specific > MessageResources for the bundle based on the name that > is configured for it, plus the name of the > subapplication. Each message bundle is stored in the > ServletContext based on the name that you gave it plus > the sub-application name. > > What I was asking was is the best/only approach. Maybe > the framework needs to do a little on behalf of the > application?. For instance, a method could be added to > the RequestUtils to aid in this task. > > 2) The second question I was asking was, suppose I > extend the ExceptionHandler to do a little more > customized exception handling. I think it would be > appropriate to have access to the message bundle there. > I believe I used to go through the ApplicationConfig to > access the servlet, that's no longer possible. So, > unless some utility method describe in (1) above is > added, it's very difficult to access the bundles. The > declarative exception handling is nice, but the > framework still needs to allow for programmatic > overrides. As I said in my post to the dev group, only > the default MessageResources is stored in the request, > thus it's not easy to get access to the messages in the > additional bundles, reducing their overall benefit. > > Chuck > > > > ----- 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]> > > > > -- > 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]>
