XML attribute value indirection

[Carlsbad Cubes mailing list]

I would like to weigh in on the side of indirection.

My experience was as part of a very small company (I was the software
guy), where I created our application initially in English. When we
ready to translate, all the translator would have to do is edit ".ini"
files, which only consisted of key=value. I was even nice enough to have
separate files, e.g., ids.ini for dialog/menu fields, and help.ini  for
setToolTipText.   For a decent sized application, i.e., one with 30 or
so dialogs, there were about 1000 ids.ini and 500 help.ini lines to
translate. But there's more - we had about 6 separate applications.
Well, for each application, there was a global ini file that could be
shared (how many times do you have to translate: "File not found: ").
Bottom line - over 3000 lines to translate. But as painful as this
sounds,  it was a no-brainer to determine with a few short ksh scripts
if the translator accidentally deleted/mangled a line. This was only
possible because the translator was 100% isolated from the dialog/menu
files, because I made it a policy to never have a single line of
"English" in the dialog/menu files. Finally, I bundled all the
translations in a a single res.jar.

Now it's 2005. I've tossed all my home grown code from reading ".ini"
files and now use ini4j from SourceForge (it uses Properties rather than
BundledResources).  I am *not* an authority on SwixML, having only used
it for less than one week, however,  I would find it nearly impossible
to guarantee the integrity of a translation if the xml files are edited
directly. *Every* field in the xml file should be exposed to
indirection. Further, to have the xml files directly exposed directly,
rather than bundled in a jar file is not acceptable (do you honestly
want to let uses to fool around with the xml files?) . I was successful
passing to swix.render a URL for the .xml from a jar file, but gave up
trying to pass a translation file via URL.

Now if you ever change you mind, I would suggest button text="${ok} />
rather than button text="@ok" /> because it would allow for a more
sophistacted buttontext="${how}${now}${brown}${cow}". This is not my
idea, ini4j also allows "{@prop/key}" if coming from the properties file
and {@env/key} if coming from the environment. Very cool.

Steve


_______________________________________________
Forum mailing list
Forum@...
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com

[Carlsbad Cubes mailing list]

List for Users of Carlsbad Cubes' Technologies and Products <Forum@...> schrieb am 20.10.05 17:21:11:
> ... Further, to have the xml files directly exposed directly,
> rather than bundled in a jar file is not acceptable (do you honestly
> want to let uses to fool around with the xml files?) . I was successful
> passing to swix.render a URL for the .xml from a jar file, but gave up
> trying to pass a translation file via URL.

Steve, I do not understand: You could not put your translation files
into a jar? If this is your only problem and reason for indirection, there
is a cure for that. Of course neither the xml files nor the .properties files
are'nt exposed to "fool around with".

Here are snippets from (one of) my build.xml:

  <property name="build.dir" location="build"/>
  ...
  <target name="dist" depends="..." description="...">
    <jar jarfile="${build.dir}/ipd-${version}.jar">
    <manifest>
    <attribute name="main-class" value="..."/>
    <attribute name="class-path" value="..."/>
    </manifest>
      <fileset dir="${build.dir}">
                                <include name="**/*.class"/>
                                ...
      </fileset>
      <fileset dir="${resource.dir}">
                                <include name="**/*.properties"/>
                                <include name="**/*.gif"/>
                                <include name="**/*.png"/>
                                <include name="**/*.xml"/>
                                <include name="**/*.xsl"/>
                                <include name="**/*.txt"/>
                                <include name="**/*.dtd"/>
                                <exclude name="**/*.bak"/>
                                <exclude name="**/*~"/>
      </fileset>
    </jar>
  </target>

  <path id="classpath">
    <pathelement path="${build.dir}" />
    <pathelement path="${resource.dir}" />
    <fileset dir="${lib.dir}" includes="**/*.jar" />
  </path>

  <target name="run" depends="compile" description="runs">
    <java fork="true" classname="..." classpathref="classpath"/>
  </target>

The bundle attributes in my swixml files are in no way special like:
<frame size="990,700" title="..." bundle="i18n.messages" id="mainframe"    
    defaultCloseOperation="WindowConstants.DO_NOTHING_ON_CLOSE">

My resource files are located (as you may have guessed) in
 ${resource.dir}/i18n/messages*.properties

To summarize, I do not have any other files than jar files to distribute my app
with (ok, one: a dtd file I cannot get rid of, but this matter is not swixml's).
The jar/distribution subject can be resolved entirely without indirection...

>        
> Now if you ever change you mind, I would suggest button text="${ok} />
> rather than button text="@ok" /> because it would allow for a more
> sophistacted buttontext="${how}${now}${brown}${cow}". This is not my
> idea, ini4j also allows "{@prop/key}" if coming from the properties file
> and {@env/key} if coming from the environment. Very cool.

Hm, IMHO this can be done through a change to  StringConverter, just split
the text and call the localizer for each part...

Yours,

Frank
>
> Steve
>
>
> _______________________________________________
> Forum mailing list
> Forum@...
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com



_______________________________________________
Forum mailing list
Forum@...
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com

[Carlsbad Cubes mailing list]

Frank,

My apologies. After ranting (just a little) earlier, I took a different tack - I wrote a tiny ResourceBundle, where handleGetObject
distinguishes between text="${foo}" and text=foo, as Babak needed. It was then easy enough to  do a swix.setResourceBundle(Bundle.Name). Your approach is much more sophisticated, but I couldn't figure out to overload ResoureBundle.getString any other way.

Do you have a (simple) workaround for Babak's Font=xxx problem? Again, I'm a newbie, but I just don't understand why all fields can't be exposed to indirection. By exposing "all", SwixML is giving the developer a choice, but he/she doesn't have to take advantage of it, nor is SwixML necessarily increasing complexity.

Steve

List for Users of Carlsbad Cubes' Technologies and Products wrote:

List for Users of Carlsbad Cubes' Technologies and Products Forum@... schrieb am 20.10.05 17:21:11:
  

... Further, to have the xml files directly exposed directly, 
rather than bundled in a jar file is not acceptable (do you honestly 
want to let uses to fool around with the xml files?) . I was successful 
passing to swix.render a URL for the .xml from a jar file, but gave up 
trying to pass a translation file via URL.
    

Steve, I do not understand: You could not put your translation files
into a jar? If this is your only problem and reason for indirection, there
is a cure for that. Of course neither the xml files nor the .properties files
are'nt exposed to "fool around with".

Here are snippets from (one of) my build.xml:

  <property name="build.dir" location="build"/>
  ...
  <target name="dist" depends="..." description="...">
    <jar jarfile="${build.dir}/ipd-${version}.jar">
    	<manifest>
    		<attribute name="main-class" value="..."/>
    		<attribute name="class-path" value="..."/>
    	</manifest>
      <fileset dir="${build.dir}">
				<include name="**/*.class"/>
                                ...
      </fileset>
      <fileset dir="${resource.dir}">
				<include name="**/*.properties"/>
				<include name="**/*.gif"/>
				<include name="**/*.png"/>
				<include name="**/*.xml"/>
				<include name="**/*.xsl"/>
				<include name="**/*.txt"/>
				<include name="**/*.dtd"/>
				<exclude name="**/*.bak"/>
				<exclude name="**/*~"/>
      </fileset>
    </jar>
  </target>

  <path id="classpath">
    <pathelement path="${build.dir}" />
    <pathelement path="${resource.dir}" />
    <fileset dir="${lib.dir}" includes="**/*.jar" />
  </path>

  <target name="run" depends="compile" description="runs">
    <java fork="true" classname="..." classpathref="classpath"/>
  </target>

The bundle attributes in my swixml files are in no way special like:
<frame size="990,700" title="..." bundle="i18n.messages" id="mainframe"    
    defaultCloseOperation="WindowConstants.DO_NOTHING_ON_CLOSE">

My resource files are located (as you may have guessed) in
 ${resource.dir}/i18n/messages*.properties

To summarize, I do not have any other files than jar files to distribute my app
with (ok, one: a dtd file I cannot get rid of, but this matter is not swixml's). 
The jar/distribution subject can be resolved entirely without indirection...

  

        
Now if you ever change you mind, I would suggest button text="${ok} /> 
rather than button text="@ok" /> because it would allow for a more 
sophistacted buttontext="${how}${now}${brown}${cow}". This is not my 
idea, ini4j also allows "{@prop/key}" if coming from the properties file 
and {@env/key} if coming from the environment. Very cool.
    

Hm, IMHO this can be done through a change to  StringConverter, just split
the text and call the localizer for each part...

Yours,

Frank
  

Steve


_______________________________________________
Forum mailing list
Forum@...
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
    

_______________________________________________
Forum mailing list
Forum@...
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com


  

_______________________________________________
Forum mailing list
Forum@...
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com