Object Application

5.8 Object Application

The object application is used for binding clients to a server. This can be done with modules, too. The problem, however, is that one module can be used in different dialogs. It may happen that these dialogs are assigned to different server processes. Therefore, when using a module, you can define where its function is to be searched. The object import passes this information on to the module. There you can define which application object is responsible for the functions in the module.

Example

dialog Main

application MyServer

{

...

}

import Modul_X "modulX.if"

{

.application MyServer;

}

...

Each function of the module Modul_X is now called on the server. In doing so, the module which is described in the interface file "modulX.if" can be programmed regardless of the corresponding server.

Furthermore, functions can be exported out of modules without having to export the attached application. This is the only case that an object’s parent does not have to be exported with. The advantage is that the designer of the module always knows on which computer his functions are running. On the other hand, however, it is not possible any more to make changes from outside.

Example

module Modul

application MyServer

{

...

export function void Calculation();

}

...

The function "Calculation" can be called from the importing module without the module knowing of the application "MyServer". These two mechanisms enable the programmer to implement independently usable modules.

5.8.1 Application assignment of module functions

A special case for the usage of functions in modularized dialogs is the use of the .application attribute at the import object to couple all functions of a module from "outside" to a special application. This procedure is described in the chapter “Programming Techniques” / “Modularization” / „Object Application“.

However, this procedure is not available when importing modules via use. As an alternative or supplement, however, the linking of functions via the .masterapplication attribute to the module or dialog can be used. This means that functions defined directly under a module/ dialog can be assigned to an application. If there is no assignment on the module, the assignment from the dialog is used. The attribute can also be indexed with an enum value. This index value should be from the range lang_default...lang_java or func_normal..func_data. This allows functions to be assigned to different applications according to their language or function type. An explicit assignment (even a null setting) at the module always overwrites/overlaps the assignment of the dialog.

Example

Modularized dialog with the functions in the module Functions.mod, where COBOL functions are attached to the server application ApplServer and all other functions to the dynlib application ApplLocal.

// Dialog.dlg
dialog Dlg
{
  .masterapplication ApplLocal;
}

application ApplLocal {
  .transport "dynlib";
  .exec "libusercheck.so";
  .active true;
}

use Functions;

on dialog start
{
  variable string Username := setup.env["USER"];
  if  ValidateUser(Username) then
    print "Age = "+GetAge(Username);
  endif
  exit();
}

// Functions.mod
module Functions
{
   .masterapplication[lang_cobol] ApplServer;
}

use Server;

record RecUser
{
  string[50] FirstName;
  string[50] LastName;
  integer Age;
}

export function boolean ValidateUser(string Username);
function cobol integer GetUserProfile(string[50] Username,
                                      record RecUser output);

export rule integer GetAge(string Username)
{
  if GetUserProfile(Username, RecUser)>0 then
    return RecUser.Age;
  endif
  return 0;
}

// Server.mod
module Server

export application ApplServer {
  .connect "server:4712";
  .active true;
}