[Resources] XMLMessageResources and Proposal

2002-10-11 Thread James Mitchell

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.keySome Value/message
/messages

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 iswhat 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)
/
  touren=A Walking Tour of the Example Application
   fr=Une excursion de marche de l'application d'exemple/
/index


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).



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]




RE: [Resources] XMLMessageResources and Proposal

2002-10-11 Thread James Mitchell

 -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.keySome 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 iswhat 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)
  /
touren=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] formatconvert 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]eparateFilesconvert file(s) from

RE: [Resources] XMLMessageResources and Proposal

2002-10-11 Thread James Mitchell

Oh, one thing I forgot to mention.

Not sure if we overlooked it, but I was wondering how are you handling
special (XML/HTML) character data?  Especially for Struts (errors.header and
errors.footer)

One peice of functionality that I am adding will (for the most part) take
care of that in a clean (IMHO) way.


Here's a snip from my sample app (ok, Craig's app, but my changes)

ApplicationResources.xml

root
!--
  This file demonstrates how you might use the XMLMessageResources
within
  the cannonocial struts-example webapp.

  --
app:mode en=/
property:html name=html.li.begin   en=li/
property:html name=html.li.end en=/li/
property:html name=html.ul.begin   en=ul/
property:html name=html.ul.end en=/ul/
property:html name=html.hr en=hr/
property:html name=html.h3.begin   en=h3/
property:html name=html.h3.end en=/h3/
property:html name=html.font.red.begin en=font color='red'/
property:html name=html.font.end   en=/font/

button
cancel en=Cancel/
confirm en=Confirm/
reset en=Reset/
save en=Save/
/button
change
message en=Your password has expired.  Please ask the system
administrator to change it./
try en=Try Again/
title en=Password Has Expired/
/change
database
load en=Cannot load database from {0}/
/database



error
database
missing en=${html.li.begin}User database is missing, cannot 
validate
logon credentials${html.li.end}/
/database

---

1. en does not necessarily have to be the attribute name
   And if using separate files (by locale), then I would use val= or
value=
   or some other meaninful attribute.
2. The app:mode and html:property are special tags reserved for processing.
3. Notice the ${replace-able.keys} within the attribute values.
   This has the same effect as Ant properties, but it works with any
   attribute's key-value (not just html:property) which is done after
   initial loading.  It will recursively replace these tokens unless an
   infinite loop is detected.


Anyway, that's some food for thought.



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]