Script Modules
A script module is a named collection of ProcScript belonging to a development object. Script modules are analogous to events and methods in other programming languages.
Script modules can be broadly categorized as:
- Triggers—modules that are executed in response to Uniface-recognized events and commands. They are declared by the trigger (or webtrigger) keywords.
- Operations—modules that are executed in response to an explicit command in another script module, which may be in the same component, another Uniface component, or a non-Uniface component via the Uniface Request Broker (URB). Operations are declared by the operation (or weboperation) command, and invoked by the activate command.
- Entries—modules that are executed
in response to an explicit command in the same component. They are declared by the
entry command and can be invoked by the call statement, or
used as a private function.
Entries are treated as if they are defined in the component object, even if they are declared in an entity or field. For this reason, it is preferable to define them in the Script container of the component, or to use partner operations instead.
Script modules can also be un-declared using the undeclare command, which prevents a previously declared module from being compiled into a component. It is primarily used to force triggers to fall back to their default behavior, but it can also be used to suppress included script modules that are not relevant in a specific component.
Triggers, operations, and entries are declared in the Script container of the relevant object, such as a component, entity, or field.
Web Triggers and Operations
Most script modules are implemented as ProcScript, but web triggers and web operations are executed in the client browser and are therefore implemented with JavaScript. However, the JavaScript is declared using the javascript/endjavascript ProcScript block. For example:
webtrigger detail javascript ... endjavascript end; detail trigger
Declaring Script Modules
Script modules are declared using ProcScript blocks that may include information on their visibility to calling operations, their parameters, and execution scope. For example, the following operation is defined in a Dynamic Server Page component:
operation load ; private method partner web ; can exchange information in HTML request-response exchange scope ; Receives no direct input from browser (has no input scope) output ; Returns direct output to browser endscope params string psInitItemId : IN endparams ... return (0) end
Depending on the script module, the declaration can include some or all of the following information:
Declaration Information |
ProcScript Instruction |
Description |
---|---|---|
Module type |
trigger
|
Keyword declares the type of the script module. |
Module name |
ModuleName |
Name of the script module. Names of triggers are pre-defined. Names of operations are user-defined. |
Component visibility |
public or partner |
Keyword determines whether the module can be called from within the component or also from other components. For more information, see public and partner. |
Browser visibility |
public web or partner web |
Keyword web declares that the module can be called from the web browser in a dynamic request-response exchange. For more information, see web . |
Web scope |
scope ... endscope |
Block of definitions that is used to control the information sent and received in a request-response exchange in a Dynamic Server Page component. For more information, see scope…endscope. |
Parameters |
params ... endparams |
Block of definitions that define the parameters of the script module. For more information, see params…endparams. |
Return value |
return |
Exit from the script module, optionally returning a value. For more information, see return and Return Values, Status Values, and ProcScript Errors . |
Module end |
end |
ProcScript modules are terminated by an end statement. If there is no end statement, they terminated by or by a command that declares the beginning of another module in the same code container, by the undeclare command, or the end of the code container. |
Script Module Inheritance
Script modules can be defined in a number of different locations and can be inherited. For example, when modeled entities are used in components, the component entities inherit from the modeled entities. If the same module is defined in both the modeled entity and the component entity, inheritance is broken, and the module in the component will be compiled.
After a component is compiled, you can navigate and examine the script modules that were actually compiled into the component. For more information, see Inheritance and Compiled Module Information.
If a ProcScript module has been un-declared, it is not compiled and will not be visible in the Compiled Module Inspector. (CMI).
Default Operations
Some script modules are treated as the component's default operations and are exposed as such in the component's signature. These modules include the exec operation, accept and quit system triggers, and the init operation (if declared). An operation with this name is automatically executed when a new component instance is created. For more information, see Predefined Operations.
Restrictions
The following limitations apply:
- Maximum size of the compiled ProcScript for an individual module is 32 kilobytes
- A maximum of 127 labels can be used per module. Labels are the names used with the blockdata, call, entry, and goto statements. The compiler generates labels for modules that do not start with an entry statement. For more information, see Compilation.
- Apart from a limit of 127 labels per module, no ProcScript statement may exceed 1023 bytes or 63 lines in total. For more information, see Statements.