I'm involved in this as a way to help others and add to list of functionality provided by this framework. Personally, I prefer DBMessageResources. (You'll see why when I finish the Management Tool for it)
This topic has been discussed many times, over many months, and it has become apparent (to me at least) that providing this functionality can be valuable for some people. My concern is whether it gets included with the distribution....I'm not going to continue on it if it is not of interest to any committers. I do have other items to work on :) James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org > -----Original Message----- > From: MARK [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 11, 2002 2:57 PM > To: Struts Developers List > Subject: RE: [Resources] XMLMessageResources and Proposal > > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
