As Mike mentioned, current work on MessageResources is happening in the Commons sandbox. The hope is that it will be promoted to a regular Commons project, and released there, so that Struts can refer to it, as it does to other Commons projects today.
I added the XMLMessageResources implementation to the sandbox a couple of months ago. It's very simple - it doesn't tackle any of the issues that TMX handles, for example - but that was the goal. If you start from some other XML format, it should be simple to generate the Commons format from that, using XSLT. The code uses the Digester (which was moved to Commons from Struts) to parse the XML files, and it uses the same file naming scheme (i.e. appended locale name) as that for regular property files. -- Martin Cooper ----- Original Message ----- From: "mihai iancu" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, December 08, 2001 7:47 PM Subject: TODO List: XmlMessageResources volunteer > > Hi all, > > I have been using for a while in production environment a "slightly" > modified version of struts.jar (now v 1.0), and developed code using the > struts framework. The biggest challenge was/is to manage the property > file that contains key-value pairs for the messages, since a large > number of developers are using it. > > I am working on an xml implementation of MessageResources that is using > ResourceBundle and a custom xml parser. The resources (and corresponding > xml master files) are split in three categories: language, > error/exception and url. The parser is designed to load files referenced > in any other xml files referenced by using an include-file tag. Each > software module is using its own set of xml files that are included in > the "master" xml files. > > This implementation is compatible with the current struts > implementation (by using a waterfall search for the value of the key in > the LanguageClass_<locale>, ErrorClass_<locale> or UrlClass_<locale> > resource class; with a consistent naming convention for the key, the > message can be pinpointed in the correct implementation class...). > > Comments, suggestions, death threats :) ? > > Cheers, > Mihai Iancu > Sr. Software Developer > > > > > > > > > > -- > 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]>
