> -----Original Message----- > From: Martin Cooper [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 11, 2002 2:29 PM > To: 'Struts Developers List'; Commons Developers List > Subject: RE: [Resources] XMLMessageResources and Proposal > > > > -----Original Message----- > > From: James Mitchell [mailto:[EMAIL PROTECTED]] > > Sent: Friday, October 11, 2002 8:33 AM > > To: Struts Developers List; Commons Developers List > > Subject: [Resources] XMLMessageResources and Proposal > > > > > > 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? ;-)
No comment ;) > 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 agree, that's why my first implementation did not allow multiple locales in the same file. In fact, it is configurable to 3 separate formats. (see below) > > > I have a feature list a mile long that I am working through, so I'm > > nowhere close to being finished. Ok, here's the Usage on the Sax DefaultHandle subclass: Usage: java org.apache.struts.util.XMLMessageResourcesHandler <mode> <fileName> <locale> where modes include: -toXML <format> convert your properties file(s) to xml in <format> style -toProp[erties] <format> convert your existing xml file from <format> into properties file where formats include: [B]yAttributes convert file(s) from or to the example format below [S]eparateFiles convert file(s) from or to the example format below [E] or ByElement convert file(s) from or to the example format below Example formats that this class can handle: 1. ByAttributes (recommended) ------------------------------ <root> <my> <buttons> <cancel en=\"Cancel\" fr=\"Annulation\" /> </buttons> </my> </root> 2. SeparateFiles ---------------- ApplicationResources.xml ------------------------ <root> <my> <buttons> <cancel value=\"Cancel\"/> </buttons> </my> </root> ApplicationResources_fr.xml --------------------------- <root> <my> <buttons> <cancel value=\"Annulation\"/> </buttons> </my> </root> 3. ByElement -------------------- <root> <en> <--- Locale is determined just above the root <my> <buttons> <cancel value=\"Cancel\"/> </buttons> </my> </en> <fr> <my> <buttons> <cancel value=\"Annulation\"/> </buttons> </my> </fr> </root> I don't have all of these modes working yet, but it is coming along nicely. What is cool about it is that you can run the Handler class off the command line and rip xml files in any of the formats from a properties file, and back. (It will even handle comments correctly....I hope ;) > > > > 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]>
