Assistant
Key Features
The basic components to create an assistant are
- dialogue forms
- business application logic (implemented with LogiView)
The assistant is based on a application logic. It is defined in the mask containing the single dialog steps like dialog step number,
predecessor number, description and the function used at the mask.
Masks are defined with the form generator of DataView. The business application
logic of an assistant is implemented with LogiView. The assistant toolbox combines
these tools and adds two more components:
- the assistant definition where the single steps of an assistant are defined
- a set of userexits that are used to work with the dialogue forms
Each dialog step is identified by a dialog step number and a reference. Userexits
and LogiView decision tables/procedures called are defined in the mask definition
with triggers.
Userexit documentation.
Naming conventions for the Assistant
For the names of the dialogue forms, the sub-lists and the LogiView procedures
please observe the following naming conventions:
- Define a unique abbreviation for each assistant you create, if possible
a three letter code (e.g. for an assistant
to create a new work request).
- Define an abbreviation for each step of the assistant. This abbreviation
should be a three letter code and must be unique in the scope of this assistant
(e.g. for the start dialogue form).
Dialog form and sub-lists
- For the name of a dialogue form combine ,
the name of the assistants' abbreviation and the abbreviation of the step,
all separated with a dash '-'. Always put a significant prefix that identifies
your company in front of the name (e.g. ).
-
For the name of a sub-list there are no strict rules, but it is a good
idea to describe the type of data that is contained in the sub-list. The
name for example defines,
that it is a list with user names. If the sub-list is a source list, its
postfix should be , if it is a target
list the postfix should be .
LogiView Procedures
- Create one logic model for each assistant. Combine the name from the significant
prefix that identifies your company and the assistants' code (e.g. ).
- Complete the name of a LogiView procedure that you use to open a dialogue
form from the assistants' code, a dash '-', the steps' code and the postfix
(e.g. ).
Dialog form
 |
Although you define a dialogue form in the same way as other forms
(such as the item or project form), there are some rules you should keep
in mind: |
Dialogue forms may consist of a main form and optional sub-lists too. Especially
for the main form it is possible to use the form generator of DataView to define
the layout.
Rules for the Main Form
Although you define a dialogue form in the same way as other forms (such as
the item or project form), there are some rules you should keep in mind:
- For technical reasons the field
has to be defined as an invisible field of the form (length 1, width 3, position
number e.g. 900).
- To be able to output a textual description please add the calculate field
to the form.
- All fields of a dialogue form (except for )
have to be calculate fields, therefore dialogue forms have no connection to
the database (so you can not refresh its contents or directly store its contents
into the database).
- The pre-mask userexit has to
be defined for a dialogue form. One of the tasks of this userexit is to add
a set of buttons (such as , and ) on the lower right
corner unless specified differently (see parameters of userexit). Remember
this when you define the layout of a dialogue form.
- While it is possible to define field select menus (or radio button menus),
it is not possible to define a select-/no select- or edit-(button-)menu for
a dialogue form (but you can for sub-lists).
- Since there is no database transaction, the pre- and post-action userexits
are not executed.
- Use the post-mask userexit to check the consistency of the complete dialogue
form and to link your business application logic to the dialogue form.
- A dialogue form is opened with the userexit .
See option to set the textual description
for field .
Rules for Sub-Lists
A dialogue form may contain one or more sub-lists. Sub-lists may be used to
display a number of values. A common way for sub-lists is to have two of them,
one as a source and the other as a target list. The user then can select any
number of records from the source list and move them to the target list.
To open a dialogue form with one or more sub-lists, the userexit
has to be called with the option . This
option takes the name of the entity plus the name of the sub-list as an argument.
Several sub lists can be separated by commas.
These are the rules for sub-lists in a dialogue form:
- Sub-lists can be defined for any entity and therefor can have a database
connection too.
- Do not use the pre-mask userexit.
Instead you may use the standard userexit
to refresh the contents of a sub-list with database access.
- The pre- and post-action userexit is executed as usual.
For the combination of source and target lists there are additional rules:
- The post-mask userexit of the target sub-list must be .
- Define a select menu for source and target sub-list to move records between
these two lists. The userexit xform_cpy_rec has to be used
for this purpose.