For a more flexible way to handle formats and layouts
Author: email@example.com (Alain Matthey)
Purpose of this paper (sent to Tom Blankers on 22.12.2009)
This paper describes a request for a flexible way to handle formats and layouts in Uniface 9.x. And this is required for both Windows and Web platforms.
I had personally a discussion about this with Gerton Leijdekker and some others of your engineers during the CU2008 days in Amsterdam. These people strongly recommended me to send directly our wish to Ton Blankers.
Our application– a Windows system for Pension Funds Administration – has become the strategic product to extend our business in continental Europe.
It is currently released for 4 countries (Switzerland, Netherlands, Belgium and recently Germany).
The core of the application is the same for all countries, except the format of dates and floating displayed on screens and document reports.
For these data the delimiters are different and depend on the country where the application is used. For reports, the format could also depend on the destination of the document.
To handle with these variances, we use the standard layout and validation mechanisms of Uniface in conjunction with the use of country-specific sets of layout templates.
The disadvantage of this implementation is that it forces us to compile the application several times, one for each country. This is the case because the layout definitions are included (compiled) in the executables. This is really constraining!
We are asking for a more flexible way to deal with layout definitions at runtime. First, to reduce maintenance and deployment costs, and also the complexity of the build process and the required infrastructure. Secondly, it will also facilitate the format handling that could be different on screens and on reports.
These format variances depends on the context in/for which the application is executed (user, client or regional configuration or options) and so, the definitions of the variances should not be part of the code.
Our Business Needs and Constraints
Initially (10 years ago!) the application was dedicated to the Swiss market. The delimiter commonly used for dates and decimal numbers is the dot (01.12.2008 and 1000.00 for example).
To check the format of these data and their display on screen and reports, we have used a set of layout templates and have defined them in fields (and in some cases to variables).
A couple of years later we extended our application for Netherlands, and more recently for Belgium and Germany. The main constraint is that the date and number format differ for each country
In Netherlands and Germany, the date delimiter is a dot sign (01.12.2008): The decimal delimiter is a comma (1000,00).
In Belgium the date delimiter is a slash (01/12/2008) and the decimal delimiter is also a comma (1000,00).
Current pratice in place
To deliver in these different countries the same application except the formats which have a specific delimiter, we relied on the Uniface standard mechanisms and layout definitions and have created 1 specific set of templates for each country. Each set has the same number of templates, with identical names in the different sets but with a content (format) that could be different.
Our application is compiled 3 times. Each compilation is executed with a different set of templates.
The final result is 3 releases of the same application, one release for each country. The releases are functionally identical except the formats.
But this solution adds overhead and complexity in our change and deployment processes and raises the Uniface environments required.
An alternative is to replace the use of layout definition by a coding of the validation of the format and the presentation using validatefield and format/deformat triggers but this was too risky and too costly. And why programming this when a standard mechanism exists in the product?
Improvement wished by Hewitt
To deal with formats in a most flexible way, the layout definitions should not (only) be compiled and integrated in the executables but should be defined in external resource (e.g. in asn or ini files) and should be manageable (get/set) at the runtime.
We could foresee the following solutions:
1. $functions which dynamically get/set the layout templates. This is perhaps possible in the init operation only
str2=$replace(str, 1, "P", "K", -1)
2. An option (setting) which forces the Uniface runtime to find the values for layout templates in the configuration file (ini/asn) instead of those defined in fields (in the compiled resources).
Similar solution already exists for widgets and fonts
PE_VAL_10_2 = -zzzzzzzzz9K99
PE_VAL_10_2 = -zzzzzzzzz9K99
The first solution offers more flexibility. We could for example set a layout depending on user preferences (application) or on the "regional and language options" (computer).
Please note that this dynamicity must also be available for variables for which templates can also be defined (display). And this is not the easiest to solve.
We strongly believe that an improvement in Uniface can't be ignored, specifically for handling the globalization and internationalization features more efficiently
Depending on the business needs, handling with different presentation formats should be possible at the runtime. This is not only required for screens but also for reports.
If the same system is accessed by users located in different regions, the same screen should support the format and the presentation based on the user preferences or the local configuration.
For reports, it must be also assumed that there are business rules which specify that the data format in the reports differ from those used in the screens. (for example a Swiss user produces an Insurance statement for a Dutch participant.)
By the way we noticed that, in Uniface 9.4.beta, the format handled in the dynamic server pages are based on field layout definition (template or shorthand). In our opinion, Uniface 9.4 (via dojo?) should offer quite urgently flexible and dynamic format and layout handling.
Is it possible to have such extensions in version 9.4, both for Web and Windows UI?
Is it possible to have such extensions in version 9.2 for Windows?
Other related wishes:
1- the possibility to define the simple quote as the thousand delimiter in the layouts.
2- the possibility to get the information defined in "regional and language options" on the Windows Client (and Web clients).
3- In Switzerland, the thousand delimiter is the simple quote, but unfortunately only comma and dot signs are supported by Uniface in layout definitions. Would it be possible to include the quote sign in standards?
Hoping you'll take this request into consideration we remain available to discuss about this with you and/or your team.
Architect and Software Developer, Hewitt Associates
Tom Blankers's answer (on 08.01.2009)
Dear Mr. Matthey,
first of all thanks for your detailed paper. We really appreciate customers thinking with us how to make improvements for Uniface.
Your paper has been discussed with some of the Lab experts on formats and layouts in Uniface. Here is their feedback summary of the issues you mentioned in your paper:
You probably already looked at the Uniface Language Setup. It allows to switch display formatting based on $language. It is limited to 1 date, 1 time, and 1 datetime format for each language. The date formats mentioned in you paper are supported. The Language Setup does not support numeric data types.
At this moment in time we are in the beta phase of the Uniface 9.4 RIA functionality. One of the areas we are looking into is to use the operating system formatting for dates and numerics, using the OS locale, into the Uniface DSPs. This will allow Uniface web apps to format these fields in the same as it done by the operating system, which is often preferred by end users. Please join the Uniface 9.4 beta program to watch the results of this investigation. You can comment on this via the Uniface User community uniface.info.
For Uniface Windows applications OS based formatting is currently not supported. We already know that implementing this formatting will require a major change in the Uniface repository. These kind of changes are made when we Uniface enters a new major release. So a future Uniface 10 would be the first option to add this functionality. When we create this functionality it will be in-line with the way it is implemented for DSPs.
Uniface request RR 157"Flexible way to handle formats in Uniface" has been created to reflect your wishes. Please refer to this number in future communication about this topic.
Also please share your request on the Uniface.info website. The more customers support a Uniface wish, the higher the changes of rapid implentation are.
I sincerly hope this feedback was helpfull. If you have further questions about this topic please contact your local Compuware representative.
Product Manager Uniface