Refer to documentation Implementation
Presentation
The header is used to identify in a unique fashion each element in this table. It is also used to enter all the information necessary on the components of the type URL.
Close
Fields
The following fields are present on this tab :
| Code identifying the current record. |
| Field used to determine the three graphical interfaces :
|
| Component title. It is notably displayed on the screen, when this latter proposes a URL choice or HTML pages. |
| Used to have a title for the URL, HTML page or XSL element, variable as a function of a context. If it is entered, the evaluated title is displayed in the place of the title, during the display screen in which this component is placed. |
| Used to refine a XSL link type. As standard, there are three XSL process types :
The "Miscellaneous" is reserved for specific/custom developments. |
| used to associate XSL with a parameter set defined in miscellaneous table 915. It will intervene in the parameterization of the screens during the characterization of the fields. |
| Module belonging to the setup. This field is used to specify whether the screen has to be created in the folder database. It is specified when the module linked to the screen is active in the folder. |
| An activity code is used to:
In this way, if the activity code is disabled, the marked element will not be useable, and the associated code (if any) will neither be generated nor can be activated. |
| URL address. It can be evaluated. Examples:
|
|   |
|   |
Close
Presentation
This tab is constructed from a unique field that is used to enter the description of a HTML page or a process in XSL language.
Close
Fields
The following fields are present on this tab :
| Used to write the XSL code or the HTML page code. |
Close
Presentation
This tab is used to enter the parameterization used by the XSL process.
Close
Fields
The following fields are present on this tab :
Local menus
|   |
|   |
|   |
| The association of a local menu with a parameter is used to supply the XSL component with a group of labels, in the user language, that can be used in its functioning. These menus are referenced to the generation of the window, in a structure that is used by the Web component. The code associated with the menus is not modifiable, but it is possible to change the local menu numbers to make other labels appear. It is possible to define up to 5 local menus in this way. Example : For standard XSL with monthly planning, the process uses the following three local menus :
Each local menu is transferred to the XSL process by a code that is fixed. Example : For the standard XSL for monthly planning, the codes are : MONTH, DAY, ABRDAY. |
|   |
|   |
Interactions
|   |
|   |
|   |
| The interactions make it possible for the user to intervene in the graph. According to the XSL, they can take different forms - drag/drop, delete, move etc. The XSL process can make successive calls to one of three supervisor sub-programs written in the Adonix language. Example : For standard XSL for monthly planning, the process uses the MAJPLAN sub-program in AMAJPLAN. It is used to assign an activity to a planning slot. A day can be subdivided into 4 slots. |
|   |
|   |
Parameter definition
|   |
|   |
|   |
| The parameters corresponding to the values that characterize several options that are used to reuse the XSL in the different contexts. A description and a default value are associated with each parameter. This value by default will be proposed and can be modified, in the screens using XSL. Example : For standard XSL with monthly planning, the process uses the following three local menus :
|
|   |
|   |
Close
This button is used to copy this information to another folder. |
This button is used to list the usage in a log file. |
In addition to the generic error messages, the following messages can appear during the entry :
the code entered must be unique in the table.
the local menu number entered must exist in the table of messages and local menus AMENLOC.
the process must be referenced in the sub-programs table ASUBPROG.
the sub-program must be referenced in the sub-programs table ASUBPROG.