Skip to main content

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

Hi Zdenek Socha,

I can see the relevance for flexible layouts and flexible syntax for some extent.

But what "use case" you have needs flexibility even in the interface (seen as "C8" changed to "C9")?

Success, Uli

It's a serious question about the reasons for your request, no mocking, no gimmiks.


Author: ulrich-merkel (ulrichmerkel@web.de)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

Hi Theo,

you may not have recognised, but Zdenìk had introduced an additional requirement just before my post.
This is about the necessity to modify even in the interface etc. of a field painted.

Business case is to provide some flexible formular
where one just paint unisex "substitutes" on your tableau.
And do the specifications at runtime.

This way, there is no need for some 50 (hardcoded) components
but just one with a bit of intelligence inside.

Success, Uli

P.S. One way to come near to that functionality runs as:

paint fields of different types next to each other,
attach left and right,
hide all fields but the one you want to use during runtime.

As Zdenìk said, unfortunately does this not work on the grid-widget.


Author: ulrich-merkel (ulrichmerkel@web.de)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

Why so complicated?

We have templates, we have libraries/$variation and $language.

The IDF could change so these templates are stored in USOURCE and distributed in .dol

Then the end-user could even change the language of the application when he is working in it.

I guess it would mean a lot of changes in the Uniface kernel, but IMHO this is how it should work...

 

 


Author: Theo Neeskens (tneeskens@itblockz.nl)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

I agree that splitbars are not so easy to handle because they follow a strict hierarchy:
 if you delete a "higher" splitbar, all the lowers disappear as well.

But if you respect that and avoid end-users can manipulate splitbars(hide then, fix them), it is a useable tool.

At least we had no problems with this type of form when we used it in production (it's some years now).

Success, Uli.

BTW, if you are not satisfied with the GridWidget as provided by uniface,
you may use the OCX-container to install a grid with better functionality.

First, it may be a lot of frustration to get the "extended triggers" working,
but you can deliver the functionality your customers are waiting for.

 


Author: ulrich-merkel (ulrichmerkel@web.de)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

Well Uli,

quite a bit. :-) It is not possible to hide a field witin a grid. Even the whole column can't be hidden, which is pretty sad. (I mean dynamicly, at runtime, of course.) So we have all fields like String, VC* and everything is done in triggres. It is very hard task to bypass Uniface default actions, like validation, and do it ourselves.

As for splits, they are fine as long as you respeckt the steps: 1) design the form, 2) deploy, 3) do not touch it anymore. But, as soon as you need to change the form, resize it, add more fields/buttons, move old fields/entities etc, the result is, that the form is messed up. AFAIK, the only way to "fix" this is to remove the state from registry (which is very hard to explain to the end user).

Zdeněk


Author: sochaz (zdenek.socha@fullsys.cz)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

Hi Zdenek,

If I read you correct, you alrady use the "different-entry fields in one occurence", but not the "hide the fields".
later addition: not because you have forgotten to do it, but the grid widget does not support hiding.

About the splitbars:
I used invisible fixed splitbars to minimize problems like: "I moved it, but now the fields are lost".

SUccess, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

Thanks, Uli. But out experiences with splits are a bit weird. Splits in Uniface are very tricky and bugy.

But... just to give you a bit deeper into our situation... we have a form, grid widget, every occurences represents main data, every column represents type of data. The grid has 40 columns right now. Every single field might be a different data type, different data. In general, the same column has the same type of data (right now), and we can accept this limitation.

There are many bad things (limitations) about grid widget, but we are still waiting for CPWR to improve it.

Zdenek


Author: sochaz (zdenek.socha@fullsys.cz)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

Now I know what you are after and there is a very easy way to do it right now:

Just a summary of the concept (worked since we had splitbars and "attatch to window border").

The basic "trick"is to overlay data-entry fields for different data types and hide all but the one needed.

One data-entry is represented by one occurence.
We paint a label-field to the left and data-entry fields (non-database) are painted between 2 horizontal splitbars . 
All fields are "attatch to right and left window border", 1 column wide (with a suitable WID() setting); checkbox is first in line .

Abolutely easy to build and use and allows all kind of widgets you want (incl. dropdowns etc.)

Success, Uli

P.S. If there is some kind of request, I will work it out in more detail as part of the "dITo" projects.


Author: ulrich-merkel (ulrichmerkel@web.de)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

Hello Uli,

just very short, but hopefully you'll get the point. We have a small part of application, where users can store data, which they need. It is completely up to them to decide, what the data is, what is the meaning and so on. Sometimes, data is just a (free) string, but it can be a string, number, date, time, a week-day or e.g. some code from code list (basic validation is automatically performed).

And we have several forms to enter these data. Everything would be just fine, if we were able to change data type and interface of painted editboxes. There are some internal checks and modifications automatically done by Uniface itself (e.g. in date field you can enter only a day - and month and year is added automatically). In our case, we need to do everything by ourselves. Life would be so much easier if it would be possible to change data type and interface (and layout) of fields.

I am talking of non-database fields, of course. By the way, the forms are a bit complex and I have some interesting discussion at CU2008 in AMS with people from lab/tech support.

Zdenek


Author: sochaz (zdenek.socha@fullsys.cz)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

Sorry, I was too quick. Missed a bit of the discussion.
I guess Gertons work is not going to solve flexible datatypes either...


Author: Theo Neeskens (tneeskens@itblockz.nl)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

Just to support this. We have dynamic layout on our wishlist for ages. Ability to access and change interface, syntax and layout of fields is very needed.

I guess, most of developers need this and mainly ability to get and set field layout at runtime (from proc code) would be very appriciated.

Zdenek Socha

PS: OMG, why this site is not Unicode ready? I even can't write my real name. :-)


Author: sochaz (zdenek.socha@fullsys.cz)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

... guess that's where my next mail goes to ... thx for the hint!

 

-GHAN-

 

PS: Congrats :) ... you are the first one to screw up the layout in this forum by posting MICROSOFT HTML ;)) i wondered if this was possible- you proofed it, haha

PS2:  this is, what spoiled the layout ... 

<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<meta content="Word.Document" name="ProgId" />
<meta content="Microsoft Word 10" name="Generator" />
<meta content="Microsoft Word 10" name="Originator" />

< !-- [if !mso] >
<style>
v\\:*
 cz2153435 {behavior:url(#default#VML);}
o\\:*
 cz2153435 {behavior:url(#default#VML);}
w\\:*
 cz2153435 {behavior:url(#default#VML);}
 .shapecz2153435 {behavior:url(#default#VML);}
</style>
<![endif]--><o:smarttagtype name="City" namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:smarttagtype><o:smarttagtype name="country-region" namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:smarttagtype><o:smarttagtype name="place" namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:smarttagtype><o:smarttagtype name="date" namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:smarttagtype><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:HyphenationZone>21</w:HyphenationZone>
<w:Compatibility>
<w:BreakWrappedTables />
<w:SnapToGridInCell />
<w:WrapTextWithPunct />
<w:UseAsianBreakRules />
</w:Compatibility>
<w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
</w:WordDocument>
</xml><![endif]--><!--[if !mso]><object
classid="clsid:38481807-CA0E-42D2-BF39-B33AF135CC4D" id=ieooui></object>
<style>
st1\\:*{behavior:url(#ieooui) }
</style>
<![endif]--><style type="text/css">
<!--
 /* Style Definitions */
 p.MsoNormalcz2153435, li.MsoNormalcz2153435, div.MsoNormalcz2153435 {mso-style-parent:"";
        margin:0cm;
        margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        font-size:11.5pt;
        mso-bidi-font-size:10.0pt;
        font-family:"Times New Roman";
        mso-fareast-font-family:"Times New Roman";
        mso-ansi-language:EN-US;}
 h1cz2153435 {mso-style-link:"Titre 1 Car";
        mso-style-next:"Normal DS";
        margin:0cm;
        margin-bottom:.0001pt;
        mso-pagination:widow-orphan lines-together;
        page-break-after:avoid;
        mso-outline-level:1;
        font-size:13.5pt;
        mso-bidi-font-size:10.0pt;
        font-family:"Times New Roman";
        mso-font-kerning:0pt;
        mso-ansi-language:EN-US;
        mso-bidi-font-weight:normal;}
 h2cz2153435 {mso-style-link:"Titre 2 Car";
        mso-style-next:"Normal DS";
        margin:0cm;
        margin-bottom:.0001pt;
        mso-pagination:widow-orphan lines-together;
        page-break-after:avoid;
        mso-outline-level:2;
        font-size:11.5pt;
        mso-bidi-font-size:10.0pt;
        font-family:"Times New Roman";
        mso-ansi-language:EN-US;
        mso-bidi-font-weight:normal;}
 p.MsoHeadercz2153435, li.MsoHeadercz2153435, div.MsoHeadercz2153435 {margin:0cm;
        margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        tab-stops:center 234.0pt right 468.0pt;
        font-size:11.5pt;
        mso-bidi-font-size:10.0pt;
        font-family:"Times New Roman";
        mso-fareast-font-family:"Times New Roman";
        mso-ansi-language:EN-US;}
 kbdcz2153435 {font-family:"Courier New";
        mso-ascii-font-family:"Courier New";
        mso-fareast-font-family:"Times New Roman";
        mso-hansi-font-family:"Courier New";
        mso-bidi-font-family:"Courier New";}
 p.NormalDScz2153435, li.NormalDScz2153435, div.NormalDScz2153435 {mso-style-name:"Normal DS";
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:13.0pt;
        margin-left:0cm;
        mso-pagination:widow-orphan;
        font-size:11.5pt;
        mso-bidi-font-size:10.0pt;
        font-family:"Times New Roman";
        mso-fareast-font-family:"Times New Roman";
        mso-ansi-language:EN-US;}
 span.Titre1Carcz2153435 {mso-style-name:"Titre 1 Car";
        mso-style-link:"Titre 1";
        mso-ansi-font-size:13.5pt;
        mso-ansi-language:EN-US;
        mso-fareast-language:FR;
        mso-bidi-language:AR-SA;
        font-weight:bold;
        mso-bidi-font-weight:normal;}
 span.Titre2Carcz2153435 {mso-style-name:"Titre 2 Car";
        mso-style-link:"Titre 2";
        mso-ansi-font-size:11.5pt;
        mso-ansi-language:EN-US;
        mso-fareast-language:FR;
        mso-bidi-language:AR-SA;
        font-weight:bold;
        mso-bidi-font-weight:normal;}
@
 page Section1cz2153435 {size:595.45pt 841.7pt;
        margin:42.55pt 72.0pt 70.9pt 133.2pt;
        mso-header-margin:35.45pt;
        mso-footer-margin:29.2pt;
        mso-paper-source:0;}
 div.Section1cz2153435 {page:Section1;}
 /* List Definitions */
 @
 list l0cz2153435 {mso-list-id:78447590;
        mso-list-type:hybrid;
        mso-list-template-ids:1031455866 67895311 67895321 67895323 67895311 67895321 67895323 67895311 67895321 67895323;}
@list l0:
 level1cz2153435 {mso-level-tab-stop:18.0pt;
        mso-level-number-position:left;
        margin-left:18.0pt;
        text-indent:-18.0pt;}
 olcz2153435 {margin-bottom:0cm;}
 ulcz2153435 {margin-bottom:0cm;}
-->
</style><!--[if gte mso 10]>
<style>
/* Style Definitions */
 table.MsoNormalTablecz2153435 {mso-style-name:"Tableau Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";}
 table.MsoTableGridcz2153435 {mso-style-name:"Grille du tableau";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
border:solid windowtext 1.0pt;
mso-border-alt:solid windowtext .5pt;
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-border-insideh:.5pt solid windowtext;
mso-border-insidev:.5pt solid windowtext;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";}
</style>
<![endif]--></p>

Author: -GHAN- (hansen@ahp-gmbh.de)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

Hi Gerton,

thank you for such a precise report what is going on in the Lab about 9.4

Can't wait to test to what degree this will simplify nowadays complex implementations.

Success, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

Uniface 9.4 will include extended localization functionality. It will include all sorts of language and region specifics formatting and conversion, like:

Language specific:
- Sorting (an ä is not the same in all languages)
- Searching (what do you expect back when you search on 'a', should it also return 'ä', 'à', 'á', 'â', 'ã', 'ä', and 'å'?
- Case handling
Region specifics:
- Time zone support
- Date & time formats of all regions
- Currency formats of all regions
- Numeric formats of all regions

All of this is implemented using the standard ICU library (see http://site.icu-project.org/) and made available via field format definitions (part of field layout definitions), Proc, and asn settings.
This functionality allows you to define and compile ones, and run everywhere.

Initially, the functionality will be available on Windows and Linux/Unix platfoprms.

Gerton (Uniface Lab)


Author: Gerton Leijdekker (gerton.leijdekker@uniface.com)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

2002, our task (as your exaple shows as well) is not so much a problem of formatting,
but replacing separators and decimal points with the characters locally expected.

Inspired by an article from Tony Martson www.tonymarston.net/uniface/tip26.html,
we used one standard format for numbers and dates and $replace to change display:

in dd.mm.yyy            we replaced "." with "/"                             and got dd/mm/yyyy
in -zzz,zzz,zzz.99       we replaced "," with "'" and "." with ","   and got -zzz'zzz'zzz,99

worked very well on 7.2.04

Success, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

Hi,

we had the same problem writing an invoice program for all the german speaking countries.

We used at first (Uniface Six) a display field, later on, we used the format/deformat trigger for this purpose.

Just a global proc handled all the formatting issues for dates and numerics.

Success, Uli

 


Author: ulrich-merkel (ulrichmerkel@web.de)

For a more flexible way to handle formats and layouts

Author: alain.matthey@aonhewitt.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.

Problem Overview

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.  

Detailed Description

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

Examples:

template name

format

PE_DATE

dd.mm.yyyy

PE_FLOAT

-zzzzzzzzz9P99

 

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

Examples:

$fieldLayoutTemplate("PE_DATE")="dd/mm/yyyy"

 

str=$fieldLayoutTemplate("PE_FLOAT")

str2=$replace(str, 1, "P", "K", -1)

$fieldLayoutTemplate("PE_FLOAT")=str

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

Examples:

Swizterland .ini:

[layouts]

PE_DATE=dd.mm.yyyy

PE_VAL_10_2= -zzzzzzzzz9P99

 

BE.ini:

PE_DATE=dd/mm/yyyy

PE_VAL_10_2 = -zzzzzzzzz9K99

 

NL.ini:

PE_DATE=dd.mm.yyyy

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.

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

Alain Matthey,
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.

Kind regards,
Ton Blankers
Product Manager Uniface

 

 


 

 

Hi Theo,

looks we are on the same point of view here:
Flexible datatypes (especially in a grid widget) is totally different from format and layout.

I see this not so much as a "presentation issue", but a job for the uniface-internal data handling.

As said, it's easy to get it working (since V7) on multi-occurence components,
but the concept will not work on the grid widget.

Success, Uli

P.S.Using it is pure magic because a group of components can be provided with
JUST 1 IMPLEMENTED ONE (plus a bit of intelligence).

Required only in a MINORITY of applications, it would be nice if we had it already in the Grid.


Author: ulrich-merkel (ulrichmerkel@web.de)
Terms & ConditionsAccessibility statement