Yes, Karapan Sapi, strips all text out and creates properties file. Very cool tool. I've been working on it, helping the author debug some things [bugs, what are those?] and have so far generated a fairly working app without writing any java code yet...of course thats to come when i apply my "business rules" but its great to get an app going and test the user interface out. It has helped me tremendously in learning Struts.
Regards, Mark *********** REPLY SEPARATOR *********** On 10/11/2002 at 12:37 PM Martin Cooper wrote: >> -----Original Message----- >> From: MARK [mailto:[EMAIL PROTECTED]] >> Sent: Friday, October 11, 2002 11:57 AM >> 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. > >Well, one reason is if you are using an translation service to create >localised message resources. TMX is the standard format for localised >message exchange, so that is likely to be what your translation service >wants to get from you, and wants to give you. > >> There is already a tool that builds >> the application resources properties file from xml (Called >> Karapan, struts application generator). > >You mean Karapan Sapi. I haven't looked at this tool yet, and didn't realise >it generated properties files. It doesn't seem to mention this on the web >site (although I may well have missed it). > >-- >Martin Cooper > > >> >> 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
