[Opensource] [REPOST] Proposal for ValidValues and i18n

[Peter A. Pilgrim]

Is the eForum sending out email? Just in case you didn't get it.
Browse this eforum thread
http://www.jcorporate.com/eforum/Browse.do?state=browseMessages&GroupId=1&ThreadId=922


Hi

( KEYWORDS: i18n, internationalisation, internationalization, foreign,
  languages, support, canonisation, canonization, auto, convert,
  automatic, conversion ; I want this message to be definitely found by
  the eforum forthcoming SearchIndexer plug-in )

I read the EDG chapter on internationalisation (i18n) and I am not
sure that the current Expresso Framework does what it says it should
do on the tin.

The problem is valid value lookup and canonisation, automatic or
manual conversion of enumerated values. I have written a eforum
SearchIndexer support plug-in, and an advanced search HTML form page
which has all kinds of fields. Some the fields are drop down menu
where you can select an option. Essentially these HTML select are
`ValidValue' objects and I need some way of internationalising the key
values. I found the support at least minimal. I am sure somebody in
the past had this problem.

I propose the following changes to API

ValidValue
===========

(1) There is are only getter (accessor) methods in the `ValidValue#, I
     propose to add the setter method as well.

	public void setValue( String v) ;
	public void setDescription( String d );


     There is no reason why we these why these methods were missing.
     Also we shouldintroduce a default constructor.


	public ValidValue();



(2) Add we should add some canonisation support. This is actual
     converting the `description' field to an i18n value from a
     resource bundle.

     The first crunch is supplying `Locale' or `Schema' or `dbContext'
     or `Uid' to the valid value. I propose that we modify `ValidValue'
     with support methods.

     Second crunch is that there possible namespace conclusions with
     the description attribute which we would use as key into the
     resource bundle. I propose that we modify `ValidValue' with
     methods to support a prefix string. The most obvious candidate for
     a prefix string is a fully qualified class name.

     So in antifact the `ValidValue' API


	public void canonize( String schemaClass, Locale locale, String prefix )


     This is method will attempt to convert the `description' attribute
     into a localised value string from a message resource bundle. If
     the `prefix' parameter is not null then the `description'
     attribute is prepended with a full stop "." to the original
     description string to make a new look up key.  Otherwise if the
     `prefix' parameter is null then original description is the look
     up key.  The key value is used to look up the description from a
     resource bundle.


     The method is equivalent to functionally calling
     `Messages.getString( String schemaClass, Locale locale, key, new
     Object[0] )'. If the key is found in the resource bundle then the
     value string becomes the new description.

     So we if have the following in enumerated values

	SORT_BY_DATE
	SORT_BY_SCORE


     and I have a Java class `org.acme.test.SortOrder' then I might
     have use the class name as a prefix which results in a look up
     like this:

	org.acme.test.SortOrder.SORT_BY_DATE
	org.acme.test.SortOrder.SORT_BY_SCORE


     All I have to do is place these keys inside a resource bundle to
     internationalise an application (e.g German).

	org.acme.test.SortOrder.SORT_BY_DATE = Sortiert von Datum
	org.acme.test.SortOrder.SORT_BY_SCORE = Sortiert von Punkten


     This is exactly what I mean by canonisation or conversion.

     I propose that we add additional convenience `ValidValue' APIs
	

	public void canonize( String schemaClass, String prefix )

	public void canonize( RequestContext context, String prefix )


     BTW: There is a `Messages.getStringForUser()' call inside the
     DBController. I do not understand all the issues here in this
     call. Could somebody explain it?

     Given that we have the new canonize calls, then I propose that we
     introduce some additional constructors.

	public ValidValue(
		String schemaClass, String prefix,
		String label, String description )

	public ValidValue(
		RequestContext request,
		String label, String description )


     These constructors would "auto-canonise" the description fields
     and then application writers could write code like this:

     public Vector getValidValues( String field ) {
	if ( field.equals( "Fruits" )) {
	    Vector list = new Vector();
	    String prefix = this.getClass().getName();
	    list.add( new ValidValue( requestContext, prefix, "1", "Apple" ));
	    list.add( new ValidValue( requestContext, prefix, "2", "Pear" ));
	    list.add( new ValidValue( requestContext, prefix, "3", "Orange" ));
	    list.add( new ValidValue( requestContext, prefix, "4", "Banana" ));
	    return list;
	}
	else
	    return super.getValidValues( field );
     }

     And of course this will work for automatic lookup values.


(3) In the `DBObject.getValuesDefault' method, valid values are
     automatically cached by key name. The cacheName is built using a
     cache key using only the fully qualified java class name of the
     DBObject. For internationalisation the cache name needs to have
     the locale specifically added to it. So that the valid values are
     cached for each language and territorum. I propose that we change
     the cache name from

	String cacheName = this.myClassName + ".validValues";


     to the following


	String cacheName = this.myClassName +
			locale.getLanguageCode()+"_"+locale.getCountryCode()+
			".validValues";


     So that we get some cache names like this:

	`com.acme.test.SortOrder.en_gb.validValues'
	`com.acme.test.SortOrder.fr_fr.validValues'
	`com.acme.test.SortOrder.fr_ca.validValues'
	`com.acme.test.SortOrder.es_es.validValues'


     The second part of this method deals with creation of valid
     values.

         myValues.addElement( new ValidValue(
                                  oneObj.getField(valueField),
                                  oneObj.getField(descripField)));


     I propose that allow value to be auto-canonised by supplying the
     schema class and locale parameters for example.

         myValues.addElement( new ValidValue( schemaClass, locale,
                                  oneObj.getField(valueField),
                                  oneObj.getField(descripField)));



(5) I will definitely add some static inner class comparators to
     `ValidValues' so that you can sort a Java collection that has
     elements by either the `label' attribute or more usefully
     `description' attribute. For example will allow application writer
     to sort valid values alphabetically by locale specific
     description with having to worry about i18n issues.


So what do you think? If you have i18n issues this is the time to talk
to me. I will be away until Sunday. It would be great to have feed
back by the time I return

Fri Dec 27 19:55:14 GMT 2002

Regards

-- 
Peter Pilgrim
ServerSide Java Specialist

My on-line resume and for interview videos about myself, J2EE
Open Source, Struts and Expresso.
    ||
    \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''