Root Window
-> Tivoli Desktop
-> Region
-> Profile Manager
-> Profile
-> User Admin Categories
-> User Admin Subcategories
Dialogs you create for use with the Application Management Toolkit
probably will be installed as User Admin subcategories. The actual
component that manages your dialog is internal, so this hierarchy
example should not be taken literally. It is for conceptual purposes
only.
Individual components of a dialog are also managed in a hierarchal
manner. In this case, the dialog is the parent that manages each
component. The components are grouped together in blocks in the
DSL source file.
Another DSL feature is that like other GUI development
environments, it is event driven. The Tivoli desktop reacts to events
such as mouse clicks or keystrokes by invoking callbacks registered
with the specified component. A callback is a mechanism that ties an
action to an event. In most GUI applications, this means that when
an action (such as clicking a button) is detected, an action (such as a
C function) is invoked.
DSL Dialog Descriptors
DSL is composed of blocks that describe the dialog or one of its
aspects. The main block always begins with the keywords
Command Dialog. This is implemented, typically, when you
develop the entire dialog using DSL. However, for a User Admin
subcategory, you would implement partial dialogs. The DSL is the
same for a partial dialog, except that it does not have a main block;
instead, it begins with the keywords Partial Dialog. For more
information on partial dialogs, see the TME 10 Dialogs chapter in
the TME 10 AEF Users Guide.
When using partial dialogs, the main block is actually in another
DSL source file. The partial dialog is loaded and managed by
another dialog, in this case the User Properties dialog.
Overview of AEF Dialogs
104
User Administration Version 3.8