The concept of LU-dictionary is important and consists of information concerning logical units, modules/components, prompts, data types, references and much more. The following sections describe the details of them and how they affect the design time and runtime environments of a Foundation1 based application.
The first definitions to make in the LU-dictionary are the basic characteristics of the logical unit itself. This information consists of name, description and component often referred to as LU-name, LU-prompt, LU-component and preferred view order by clause. They are all stored in the view comments for the main view of the logical unit or in package globals for the base package of the logical unit. The implementation is different.
The information can be seen through the view USER_TAB_COMMENTS for the
database owner of the Foundation1 instance.
The primary descriptions for each field that would be included are as below:
| Field | Description |
|---|---|
| LU | Logical unit name specified with maximum 25 characters |
| PROMPT | Logical unit description |
| MODULE | Component name for the logical unit |
| SORT | Preferred order by clause (used by Foundation1 Property) |
LU='<LU-name>^PROMPT=<LU-description>^MODULE=<Module-name>^ SORT=<Order by-clause>^'
The LU-name and LU-component are also placed in global variables called lu_name_ and module_ for all packages of the logical units. These globals are important and are used in system services to list all logical units in the current environment. Note that due to performance reasons, these globals must be placed in the beginning of the package header (within lines 2 and 5).
PROMPT Creating DEMO_ORDER_API specification CREATE OR REPLACE PACKAGE DEMO_ORDER_API IS module_ CONSTANT VARCHAR2(25) := 'DEMORD'; lu_name_ CONSTANT VARCHAR2(25) := 'DemoOrder'; .. ..
For the attribute definitions, there is much more information to set than for the logical unit itself. The information consists of several flags which are concatenated into one single comment string for each attribute (=column). This string is stored in the column comments for the main view of the logical unit. This information can be seen through the view USER_COL_COMMENTS for the database owner of the Foundation1 instance. An example for the column DEVELOPMENT_PROJECT.PRIORITY is shown below:
'FLAGS=A-I-L^DATATYPE=STRING(5)^PROMPT=Prio^REF=ProjectPriority^'
The column is a non-mandatory attribute (non key) and has no restrictions for insert but cannot be updated. The attribute is a string of five bytes and the text 'Prio' is used in the LOV (where this column is included) for the current LU in runtime and maybe used by the class library at design-time in the future. This attribute is connected to the LU ProjectPriority which supplies this field with LOV-functionality. This reference might be to an IID-domain, but if not, the REF-flag is also used for restricted delete of the referential logical unit or cascade operations if the column is a parent key and the option CASCADE is specified.
The primary descriptions for each field that would be included are as below:
| Field | Description |
|---|---|
| FLAGS | Column characteristics primarily used at design time |
| DATATYPE | Data type and length used at design time |
| PROMPT | Prompts (in language PROG) used for headers in the LOV |
| REF | References to logical units used at design-time and in runtime |
The column characteristics are meant to give design support for runtime field behavior (though the LOV-flag is used in runtime to retrieve included attributes in the LOV).
FLAGS=<Key><Mandatory><Insert><Update><LOV>
The parent key is included in the parent key, but also references foreign keys.
The key is often referred to as primary key (single column), unique identity.
Flag Possible values KEY P = Parent key K = Key A = Attribute MANDATORY M = Mandatory - = Not mandatory INSERT I = Insert allowed - = Insert not allowed UPDATE U = Update allowed N = Update allowed if NULL - = Update not allowed LOV L = Included attribute in LOV - = Not included
The data type and length can be coded as below where the data type values can be STRING, NUMBER or DATE. The semantic of NUMBER(2) and NUMBER(2,0) should be the same.
DATATYPE=<Datatype>[(n,[m])][/<option>]
where n is the length in bytes for strings or n and m represent precision and scale for numbers.
The options for the data type-definition is similar to the one used in IFS Client Developer.
Datatype Options NUMBERCURRENCY, DECIMAL, PERCENTAGE, UNFORMATTED, INVISIBLESTRINGLOWERCASE, UPPERCASE, UNFORMATTED, INVISIBLEDATEDATE, DATETIME, TIME, UNFORMATTED, INVISIBLE
The Prompt is used as the name for the column when interacting with the end-user. The prompt text is used as generic field and column label and is automatically generated in client windows at the design time. This text can be translated through the standard translation tool within IFS/Localization.
PROMPT=<Column description>
The package Dictionary_SYS has several services to fetch information about the logical unit and its characteristics. There are also several services which may be used to list all views and packages included for a specific logical unit. All of these interfaces are private and protected ones and may be removed or different between releases of Foundation1.
The services within Dictionary_SYS also supports server defaults in name conventions, when generating definitions for the LU-dictionary for the PL/SQL-code got from the LU-tools. The list below describes in general terms the different services in Dictionary_SYS:
The classes defined in the client framework are implemented as QuickObjects and have some additional properties that can be set at the design time by using Foundation1 Properties. See developers guide for more information regarding Foundation1 properties.