Some Screenwise concepts

TOC

 

This section can be found in the Rb file creation wizard and in the settings page of the editor.

The "code for" combo has choices- . Choosing to create exception code causes generation of the exception class that uses resource bundles.

The default locale checkbox if checked will cause the generation of code that can internationalize messages for 1 locale whichever is current at runtime.

The multiple locale checkbox if checked will cause the generation of code that can internationalize messages for multiple locales.

All code will be generated inside the same package as the rb file.

If rbFileName  is the name of the rb file then depending on the checked checkboxes the following code will be generated. (KEY1 is one of the entries in the rb file.)

The default locale message code: The generated code will have methods like RbFileNameDLMsg.getKey1Msg(int param1, String param2, Date param3, Integer param4, long....) which have a return type of String.

The multiple locale message code: The generated code will have methods like RbFileNameMLMsg.getKey1Msg(Locale locale, int param1, String param2, Date param3, Integer param4, long....) which have a return type of String.

The exception code will have factory methods for creating the exception. There is no public exception constructor. To construct an exception the appropriate get method must be called.

RbFileNameException.getKey1Exception( int param1, String param2, Date param3, Integer param4, long....) or

RbFileNameException.getKey1Exception( int param1, String param2, Date param3, Integer param4, long...., Throwable cause)

Typical user code for the exceptions will be throw RbFileNameException.getKey1Exception( param1,  param2, param3, param4, ...,  cause) ;

In the catch clause the exception can be caught and its String getMessage() or String getMessage(Locale locale) method can be invoked.

Caching

The DLMsg code has two options Depending on the option used the generated code with cache the resource bundle accordingly.

The MLMsg code has more options

Depending of the option used either there will be no caching or a hashmap or a hashtable will be used for the caching of resourcebundles. If a prior cache is chosen then the cache is built only once for all the resource bundles before they are actually used. If prior cache is not used then the resource bundles are cached on the basis of their first use. By all the resource bundles what is meant is resource bundles of different locales.

If "code for"  is specified as Message the 2 with "factory for" combos shall have the following options

Code Distribution indicates the files that will be generated.

Keys

Keys are maintained in interface classes or enums(if using Java1.5). If only one of DLMsg or a MLMsg or the Exception is to be generated then the interface is Nested inside the generated code. Else it is generated in a java file named RbFilenameKeys. The keys can be of type String or ints or enum. The interface will have code like String KEY1="KEY1" or int KEY1=0; If the autokey checkbox is checked this hardcoding of the key value inside the interface class is eliminated and the key values are computed (only once). If the frozen int is  selected as the int flavour then the keys inside the properties files will be numbers and not text based

UseInferer checkbox is used when the keys are automatic. When useInferer is used the first key is loaded by means of invoking a Ctrl.getFirstField() otherwise it gets loaded by explicitly identifying  the interface as in Ctrl.getFirstField(RbFilenameKey.class).

This section can be found in the Rb file creation wizard and in the locales page of the editor.

The table shows all the available locales. The working locales are first selected from these.

A working locale can be primary, display or both.

Unchecking the synchronize checkbox causes the display to become as shown below.

The >> & -< buttons can be used to configure the locales.

Properties files will be generated from the rb file only for locales marked as primary.

On the other hand in the entries screen only display locales will be visible. This allows the user to focus on specific locales inside the editor. The locales for which the properties files will be generated need not be the same, they can be a subset, a superset or a mix of these locales. All locales whether display or primary must however be from the working locales category.

Keys are added, and updated and removed from the keylist with the aid of the textbox and the buttons under the list.

When a keyList is selected it enables the controls to the right of it. It aso allows the laocale list to be enabled.

For each key parameter types and name can be defined.

Parameter types possible are "int", "long", "short", "byte", "float", "double", "java.lang.String", "java.util.Date", "java.lang.Integer", "java.lang.Long", "java.lang.Short", "java.lang.Byte", "java.lang.Float", "java.lang.Double". Of these other than Date and String type all the parameter types can support plurals and for these types the support plurals checkbox is enabled. A sampleData can also be fed in for the purpose of preview.

For each key comments can also be defined using the controls above the parameter table.

Whether it is a plural table or main table of the mixed content the fragment type can be "..." meaning text or any of the parameter names.

If the convert radio is checked the preview area will show a preview of the internationalized message for the selected locale (in locale list) using the sample data provided in the parameter table.

For locales like "ta" for which a keyboard mapping has been made available the use keyboard mapping option is enabled and if checked will cause display of the message in that script in the preview.

If the display does not look satisfactory one can also check the use browser option and probably get a better display.

Note in the next release as and when that happens it is likely that this dependency on the usebrowser may be reduced due to the provision to configure preview font locale wise for keyboard mappings.(one of the easier TODOs)

How to feed in the locale values.

After selecting the key and locale code in the key list and locale list one can enter text portions of the value by setting the fragment type to "..." and feeding in the text via the fragment content textbox.

If however the fragment type selected is not "..." but a parameter name then in place of the fragment content textbox one will find a format combo or a plurals message depending on whether or not the parameter supports plurals or not. If the type is a string instead of the format combo one shall find a format message stating that there is no formatting done for strings and any formatting like enclosing quotes etc should be done using the "..." types. When faced with the format combo one just selects the appropriate format. In cases like the Date type the combo may be non-read-only allowing entry of custom formats that follow SimpleDateFormat conventions. For parameters of plural types the tabs-zero, one, multi become enabled. Inside these the user may build content for the plural choice based on same principles.

Shows the plurals tab enabled when a parameter name of type plural is selected.

Shows the plurals tab disabled when a parameter name of type non-plural or "..." is selected.

Double clicking on the table will bring the selected type and content/format/message down so that it can be edited.

Selecting a string type fragment type will bring the format message.

Selecting a plural type parameter brings the plural message.

When the parameter select is not a plural type or is being selected from within the plural tabs and is also not of type string or Date a read only format combo is made available.

Had the type been Date the combo would not have been readonly and the options would have pertained to date and Time and sice it would be a non-readonly combo it would also permit feeding in of custom formats.