iMo Communities

The implementation must be in sync with the design.

Description: Every public and protected method, attribute or property must have a description.

Pre- and post condition: If a method depends on earlier methods / properties to be set, this must be identified as preconditions.

Scoping of methods, properties and classes in the design is essential

• Only methods/properties that should be called externally should be marked public.

Support utilities
There are several frequently used functions which can be seen as extensions to the ABL. This kind of generic behavior can be placed in support classes.

Support classes are independent classes that can be used in your application program. They should NOT depend on the availability of other modules or even iMo being running or installed. Support libraries depend only on support libraries.

In a lot of situations operations of support classes are completely stateless in which case they should be programmed as being static.

.

Programming Styles

Several programs come from several sources and different programmers following different styles. Whenever possible follow the style from the original programmer (casing of keywords, do-end position etc).

In case of a new source (no original programmer), follow the following style:

Keywords lowercase

No abbreviation of keywords

Use 4 space indentation (tab = 4 spaces)

In an if-then-else construction put the do: on the same line (“if ..then do :”)

The iMO classes are constructed in such a way that in the normal execution path there is no copying of datasets. Therefore all datasets are defined ‘REFERENCE-ONLY’ by default and all dataset parameters are passed ‘BY-REFERENCE’ or identified by a handle. In normal execution the dataset that is used during a fetchData or saveData is the dataset that is passed as an input or output parameter to the Api.

In a number of situations the dataset that is used in the application can become quite large. One of the reasons for this is that a dataset contains both top-level as well as child-level tables.

From an oo-point of view an object is just an object and should contain all the details that belong to that object. From a performance view you might want to delay the load of the details until there is really a need to use it.

Sample:

The normal load of a dataset is to load a complete dataset containing the complete definition of all entities that are available in the database.

This can be filtered in several ways:
• Using filters on the fields of the dataset tables
• Using query(parameter) identification for the type of query that has to be loaded
• Using options

Sequence diagram:
The used query is part of the context. This makes it hard to identify the query in a sequence diagram. The queryName can be identified in the sequence diagram using pseudo context in the form of named parameter.

There are several iMO patterns to load related data. The iMO pattern that is selected depends on the relation between the class and the class that is responsible for the related data.

In this pattern is described how related data can be loaded from related business entities.

Example:

There are several iMO patterns to load related data. The iMO pattern selected depends on the relation between the class and the class that is responsible for the related data.

This pattern describes how related data can be loaded from related data access objects.

Example:

See the sub-topics below:

Supplying unique id’s
There are several types of a unique id’s.
• The id is globally unique (a GUID)
• The id is a unordered sequence (gaps allowed)
• The id is a ordered sequential value (no gaps allowed)

Furthermore the id can be assigned at multiple times:
• Up-front
• On the server

• During the transaction (this has to be the case if the id is an ordered sequential value with no gaps allowed.
• Just before the transaction

In this whitepaper (and related sub-pages) a number of iMO specific patterns are described that should be used when working with the iMO.

This whitepaper focuses on more complex data retrieval and data storage operations. These are mainly operations that require interaction between multiple objects in the OERA layers.
The patterns are described using several mechanisms:

• A sequence diagram describing the behavior
• A class diagram giving an overview of the participating classes
• Code fragments to show how the implementation should be done

Suppose we have a frame with details for a department and a button to start the control with all employees.

In a picture:

In the frame (vwdepartmentframe1.w) there will be some code required to propagate the action to the control:

ON CHOOSE OF btnEmployee
DO:
  phObject:action('startEmployee').
END.

In the control the action need to be handled correctly:

method public override void Action(pcAction as character):
  case pcAction:
  

Suppose we have an employee frame with a lookup button on it to select the department of the employee,

In a picture:

In the initObject of the frame the field has to be converted to a lookup field using the following statement:

     ifacecontainer:fieldManager:AttachLookupField (
        ttEmployee.deptCode:handle in frame {&frame-name},
        "sports2000.client.ctsearchdepartment":U,
        "deptCode":U, ?).  
 

This book contains several generic ‘howto’s.

This document briefly describes the design, configuration and usage of the service manager.

Introduction
The service manager is the part of iMo that is used for calling services that are located in functionally different parts of the application. The service manager is responsible for locating the service and communicates with the service according to the format that is required by the service.

Communication with a service can be done in several ways:
· Direct (service is hosted in same container)
· AppServer
· WebService
· ESB (using webservice)

This book will contain whitepapers for each of the iMo managers

The iMo project is nothing but a container for issues