Patch for org.apache.commons.resources.message
Hi Gang (Craig McClanahan in particular), I would like to offer the enclosed patch for the classes in the org.apache.commons.resources.message package. This is a very fine package that provides a nice mechanism for localizing messages maintained in a properties or XML file. I noticed that the properties file and XML file is loaded by the class loader for the PropertyMessageResources or XMLMessageResources classes or a derived instance of these classes. Ideally one should be able to specify the class loader without having to derive these classes. I propose the addition of a new factory method in the MessagesResorucesFactory (and the concrete derivatives) that takes a ClassLoader as an argument: public abstract MessageResources createResources(String config, ClassLoader classLoader); I further propose the addition a new constructor for MessageResources and its concrete derivatives: public MessageResources(MessageResourcesFactory factory, String config, boolean returnNull, ClassLoader classLoader) The MessageResources class is augmented to hold a protected instance variable with the ClassLoader. If a class loader is not provided (through one of the existing constructors), it is obtained from this.getClass().getClassLoader(). Then, the file input stream in the PropertyMessageResources and XMLMessageResources is loaded like this: is = this.classLoader.getResourceAsStream(name); where the classLoader instance variable is set from the constructor (and factory method) or obtained from the class instance (if a class loader was not explicitly specified). If we do this, we can rest assured that the properties (or XML) file is retrieved using the proper class loader. This is an issue in a J2EE 2.x application server where the class loader associated with these utilities (perhaps loaded by the EAR class loader) may not be able to see the resource bundle property files in (let's say) a Web application. The enclosed zip file holds the modifications. Thanks for considering this patch. I am sorry if it is not presented in the appropriate format. <> -- Erik. Erik K. Worth Senior Software Engr. / Architect Altoweb, Inc. 1731 Embarcadero Rd. Palo Alto, CA 94303 (650) 251-1663 <> message.zip Erik Worth.vcf
RE: Data conversion
Hi Viral, I see. Actually you would probably specify a JXPathContext on X and identify the field like this: A/X. Perhaps you could create your own tag(s) that push or pull the property through a Capco mapping. The tag would have to specifiy the source/destination property (A.X) and mapper (from the mapping configuration). It may be a lot of work and you would have to maintain configuration information two places (the JSP attributes and the mapper), but I think it would allow you to convert A.X as you want. I do my mapping between the FormBean (which holds properly formatted strings) and the business data object used by the logic components (rather than bewteen the tag and the bean). You have probably already ruled that approach out for whatever reason. Good luck. -- Erik. -Original Message- From: Viral V. Tolat [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 2:28 PM To: '[EMAIL PROTECTED]' Subject: RE: Data conversion Erik, Thanks for your suggestion. JXPath looks very interesting but I'm not sure it would solve our problem since it's not clear how we could specify a JXPath object for each property on the page. What we want to do is along of the lines of the following: Say there's a Bean A with X getX() and setX ( X ). In the JSP itself we'd like to specify the mechanism to convert X to and from a string. We want to do this in the JSP since there may be many ways to view an instance of X. We would expect to build a bunch of converter classes that do String toString ( X, HTTPServletRequest ) and X fromString ( String, HTTPServletRequest ) for each different conversion. We don't want to add methods to A to do this as A should know nothing about presentation of X or about servlets. We can use the existing pattern A.X to access X from A. That's okay for us and we don't need anything more sophisticated. We don't want to add adaptor methods to A that will convert X for two reasons. One is that we would need another A for every different presentation of X. Second is that there may be many instances of X in an object graph that starts with A. Lastly, the conversion needs information in the ServletRequest since there is context information there that will drive the conversion. The problem is that in the current code, the conversions are done in different places and span BeanUtils, ConvertUtils and RequestUtils, so its hard to find a solution that won't be brittle to potential changes in these files. Thanks, Viral -Original Message- From: Erik Worth [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 1:04 PM To: [EMAIL PROTECTED] Subject: RE: Data conversion Hi Viral, I am using the Capco Mapper for data conversion because it basically allows you to map from one abritrary structure to another. I am not using the standard bean getters and setters, but rather setters and getters that use JXPath (http://cvs.apache.org/viewcvs/jakarta-commons/jxpath/). The Capco Mapper is highly extensible and can be extended (via sub-classing rather than editing the original source) to transform virtually anything. I am able to convert from one bean to another, an XML DOM tree to bean hierarchy (and vice versa) and from one DOM tree to another (had to write my own getters and setters for XML DOM traversal, but that was no big deal). You can craft Converters that leverage java.text.MessageFormat to piece together new strings from a resource bundle and some arguments, render a java.util.Data according to a simple data format patter, or extract information out of a string using regular expressions. The architecture is very flexible and well thought out. The only problem I have seen with it is that it references the old struts utilities that have now been moved to commons. -- Erik. -Original Message- From: Viral Tolat [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 12:13 PM To: [EMAIL PROTECTED] Subject: Data conversion Is there any intent to modify the code to centralize conversion of strings to objects and reverse? Currently, ConvertUtils is used to convert strings to primitive objects, however, toString is used to convert the object to a string. We'd like to integrate in a data conversion framework but to do this cleanly we need a cental place where all data conversion happens. In addition, we'd need to be able to access the request or page context in order to provide custom conversions on a per page basis. We've looked at the transformations extension and the Capco Mapper, however, we don't see how the transformations can be used with html:text tags to provide data conversion from strings to objects since the Tag is not involved at all in this process. Thanks
RE: Data conversion
Hi Viral, I am using the Capco Mapper for data conversion because it basically allows you to map from one abritrary structure to another. I am not using the standard bean getters and setters, but rather setters and getters that use JXPath (http://cvs.apache.org/viewcvs/jakarta-commons/jxpath/). The Capco Mapper is highly extensible and can be extended (via sub-classing rather than editing the original source) to transform virtually anything. I am able to convert from one bean to another, an XML DOM tree to bean hierarchy (and vice versa) and from one DOM tree to another (had to write my own getters and setters for XML DOM traversal, but that was no big deal). You can craft Converters that leverage java.text.MessageFormat to piece together new strings from a resource bundle and some arguments, render a java.util.Data according to a simple data format patter, or extract information out of a string using regular expressions. The architecture is very flexible and well thought out. The only problem I have seen with it is that it references the old struts utilities that have now been moved to commons. -- Erik. -Original Message- From: Viral Tolat [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 12:13 PM To: [EMAIL PROTECTED] Subject: Data conversion Is there any intent to modify the code to centralize conversion of strings to objects and reverse? Currently, ConvertUtils is used to convert strings to primitive objects, however, toString is used to convert the object to a string. We'd like to integrate in a data conversion framework but to do this cleanly we need a cental place where all data conversion happens. In addition, we'd need to be able to access the request or page context in order to provide custom conversions on a per page basis. We've looked at the transformations extension and the Capco Mapper, however, we don't see how the transformations can be used with html:text tags to provide data conversion from strings to objects since the Tag is not involved at all in this process. Thanks
RE: .NET and Struts...
Hi Gang, I realize this is tangential to Craig's original request, but I just had to comment... >The IDE would then compile your application and create an ASPX page that displayed >your form and a class file that would be used to handle events on the form (on the >server side). So the compiler actually generates JavaScript code which will make calls >out to the server when things like the "lostFocus" even happens on a text box, or the >"Click" event happened on a button. From a distributing computing standpoint, I would hate to have to host a web application that generated server events on things like a "lostFocus" event on the web page. This sounds like a recipe for network congestion and an overwhelmed server. It is a bad idea to make it easy for developers do this sort of thing. Such features make it easy for a developer to not only shoot themselves in the foot, but blow their whole leg off. -- Erik.
