[Opensource] [REPOST] Proposal for ValidValues and i18n

[Michael Rimov]

<snip> <snip>

At 04:40 AM 12/29/2002 +0000, you wrote:

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

+1



>         public ValidValue();

+1




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

+1



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

+1 I'm with you so far :)

>(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

You're losing me here.... how do you differentiate ValidValues that are 
attached to MessagesBundles, and ValidValues that are attached to a 
specific database table?  If the ValidValues are based upon values in a 
database table, then you don't want any canonization, and therefore, there 
would be only a single cache name no matter what the client's Locale.

Ho about instead we create two different types of ValidValues? The first is 
the default one, and the one with the Canonization is a derived 
class?  This way there could potentially be minimal API/usage changes when 
dealing with a database table, but you could canonize for Internationalized 
valid value items???


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

The problem here is that you'll have to load multiple caches even if the 
underlying values are the exact same (which is what occurs if the 
'Description' is database fields.


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

Again, if you're dealing with a database table, you won't want 
canonization. Perhaps, however, if we have the two different types of 
ValidValues, then the canonization could automatically take place like you 
propose??



>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

You're selling me. :)  Am I missing something when it comes to how to deal 
with the various database data???

Thanks for the proposal, and sorry I didn't get back to you faster on 
it.  I've got to write some folks on i18n enhancements for dealing with a 
far east installation with Expresso, so I may be able to shortly get more 
info back to you.

                                                 -Mike