Why use xml for the message resources in the first place? Using XMl doesnt add any inherent value. The properties file is fine, easy to use/read, and XML is way too wordy, constricting. Seems like its not advantageous to me, perhaps Im missing something. There is already a tool that builds the application resources properties file from xml (Called Karapan, struts application generator).
Regards, Mark Martin (and others) >> >> On a suggestion by Craig, I had a look at the commons resources >> XMLMessageResources. It appears (and I could be wrong) that this >> implementation expects a structure similar to this: >> (I couldn't find any samples or test data, so I just guessing >> by browsing >> the code) >> >> <messages> >> <message key="some.key">Some Value</message> >> </messages> > >Yep, that's it. Looks pretty lame, huh? ;-) Let me explain my thinking when >I wrote it, which might make it look a little less lame (I hope :). > >I figured that there were a few possible approaches to this. > >1) Define our own XML format. >2) Pick a standard format. >3) Somehow allow the use of an arbitrary format. > >My first inclination was to do (3), because that allows the most flexibility >for people to use whatever they already have, or to define whatever they >want, and then specify a mapping so that we could read it. However, at the >time, I hadn't a clue as to how to go about implementing such a thing. (But >see below.) > >My next thought was to go with (2), and I looked at TMX for a while. >However, TMX is a pretty complex format, and it wasn't at all clear to me >that it was (a) appropriate and (b) feasible to use that as the basis for >the kind of message resources we're talking about here. In case you're not >familiar with TMX, you'll find the scoop here: > >http://www.lisa.org/tmx/ > >That left option (1). In implementing that, I decided to follow the KISS >principle, and create a minimal XML format that maps pretty directly to what >is done with property files. My thinking was that, with such a simple >format, it would be straightforward for anyone already using their own >format to write an XSLT stylesheet to convert their existing XML files into >the XMLMessageResources format, most likely to be run as part of their web >app build process. > >Some time ago, I sent a message out (to struts-user, I think) about what >people really wanted in an XML message resource implementation. The answers >that came back said we need to do option (3) above. As I said earlier, at >the time I wrote the current code, I had no clue how to do this. > >However, that was before the Digester's XML Rules package existed, and also >before Betwixt existed (or at least before I had any idea what it was). With >these tools, I now think we have a good chance at being able to create a >very flexible "use whatever XML format you like" implementation for XML >message resources. > >> >> or is it... >> >> <messages> >> <message key="some.key" value="Some Value"/> >> </messages> >> >> >> How do you handle special characters in the values? (<, >, ") >> >> >> >> [Proposal] (Sort of) >> Would it be feasible to allow an open structure? >> What I mean is....what about allowing a structure like this: >> >> <index> >> <heading en="MailReader Demonstration Application Options" >> fr="Options D'Application De Démonstration De MailReader"/> >> <logon en="Log on to the MailReader Demonstration Application" >> fr="Entrez à l'application de démonstration de >> MailReader"/> >> <registration en="Register with the MailReader >> Demonstration Application" >> fr="Inscription à l'application de démonstration >> de MailReader >> "/> >> <title en="MailReader Demonstration Application (Struts 1.1-dev)" >> fr="Application De Démonstration De MailReader >> (Struts 1.1-dev) >> "/> >> <tour en="A Walking Tour of the Example Application" >> fr="Une excursion de marche de l'application d'exemple"/> >> </index> >> >> > >Personally, I have always favoured keeping multiple translations in separate >XML files. This avoids issues related to different character encodings >required for different languages. However, I don't recall whether this >matches with TMX or not. > >> I have a feature list a mile long that I am working through, so I'm >> nowhere close to being finished. >> >> If I complete this, is it feasible to add it to sandbox >> resources or struts? >> If not, then I will drop it and work on other issues (pending >> Struts bugs). > >There was a brief discussion on whether or not we would try to migrate to >Commons Resources for Struts 1.1, but I don't recall the outcome, so I'll >need to go back and dig that up. > >-- >Martin Cooper > > >> >> >> >> James Mitchell >> Software Engineer/Struts Evangelist >> http://www.open-tools.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]>
