Technical White Paper (page 4)

   1   2   3   [4]   5   6   7   8   9   10  

Translation

The element text for rows and column headings, together with the element's help text and optional values in list boxes, are kept in a language directory within the project for easy translation. The language variables can be exported to the System Manager and automatically expressed to the presentation screens depending on the supported languages.

It is possible to generate double-byte character databases and the Designer provides for the various options by element.

Element Edits

Basic information about the data can be defined at the element level - optional or mandatory input on maintenance, and optional values on fixed list boxes such as "Yes/No" or "Ordered/In Progress/Delivered".

Rules

It is important to note that rules are purely calculations based on elements - and not based on programs, as is the traditional way of building logic. This means that the action is defined at the lowest level of detail and more easily understood by the user, for example:

• Edit rule - output a message if the values are incorrect
• Default rule - output today's date if the input is blank
• Display rule - highlight that the bank balance is negative
• Update rule - update derived elements from base elements
• Transient rule - convert from a foreign to a local currency
• Personalization Rule - personalizes the output on the first frames by user

Complexity

Do not assume that because the rule syntax is not complex that the computations and programs cannot handle complex processes. Most of the program logic associated with traditional logic is automatically generated:

• Getting screen forms
• Redefining element names within functions
• Reading and writing to entities
• Handling translation of text elements
• Prescribing user formats
• Handling screen and element security

By eliminating what can be automated, the rules are clear and concise. This ensures that as the business changes the rules are changed with relative speed.

Callable Functions

If the project has a requirement for a function that is not included in the Designer's library of functions, it can be created as an object in any language - although consistency with Java™ is always recommended. The object is defined as a Callable Function within the Designer with passing parameters (in, out, or shared). The Business Analyst can then use the function within the rules.

Callable functions are important as they extend the boundaries of the design. Technicians can build complex functions that are then re-used by the Business Analyst. Examples include linear programming computations, web services, data access API's, etc. A library of common functions is shipped with the Designer and we add to this as part of our support service.

   1   2   3   [4]   5   6   7   8   9   10