Structure source code
- Last Updated: March 30, 2020
- 2 minute read
- OpenEdge
- Version 12.2
- Documentation
By the time you have localized an application to address the needs of users in a variety of locales, you might find yourself with many editions of that application. Maintaining and testing these editions can be costly, so it is important to implement much of your application in a single structure of source code that the various editions share.
Generally, the more detailed an application, including the user interface, the more regional variations it will encounter. Streamlining certain operations and processes can help limit the number of international issues that your application must handle. However, streamlining does not mean making your application a generic one that is strongly based on one locale's practices and requirements. Even a streamlined application should be examined closely to make sure that it does not make worldwide users adapt to the conventions of a single country. Ideally, a localized application appears as though it originated in that locale. If you decide the overhead of creating, testing, and maintaining more complex, localized code is not feasible, at least make sure that your streamlined application does not create usability problems for any locale.
There are instances when the strategy of creating local modules
that the shared source code calls is necessary. For example, a real-estate
application that manages property-tax information might be structured
so that the part of the code that handles taxes is completely modularized,
with the legal, business, and cultural issues—tax laws, currency
conventions, rounding rules, debit/credit notations, calendar variations—addressed
separately for each country. The main procedure conditionally calls
the appropriate procedure, such as ger_tax.p, dan_tax.p,
or no_tax.p, as the following code shows:
|
The CASE statement uses the value of the CURRENT-LANGUAGE variable,
which your application must set, to determine which procedure runs.
The procedure no_tax.p is a module you use if taxes
do not apply. The other modules are fully localized, as they contain
the tax laws and financial conventions for Germany and Denmark.
By consolidating localization requirements into a few clearly identified
modules, the major portion of the application can remain in a single
set of source code.