Object ClassesObject ClassesThe development and run-time environments make use of classes of objects. These objects define how the system will build pages, manage security, group application elements and handle interactions within the database environment.
Each of these objects supports some/all of the following events.
Any object can be defined as being secured to single or multiple security (user) groups. Any object secured in this way will be evaluated at run-time against the user security group list (stored within the "syssecurity" common block item). If the user does not belong to one of the security groups indicated within the object security groups, then the object will be omitted from the page.
Use the "add"/"delete" buttons to add and remove security groups to the object. User groups can be defined within the "user administration" section of the administration environment.
Root objects can be assigned to modules. This assists in clear assignments of objects to well defined application components.
Non-root objects cannot be assigned to modules (the system will allow the assignment but it will not have any effect). This means that table and page sub objects (syspageobj and systabobj) can be made to belong to a module through the module definition held within the container object (syspagemain and systabmain).
Descriptions are not required within the property definition system. Some objects (like the HTML object and the subroutine object) will use the description for display purposes within the development environment.
This option is only available to table sub objects (systabobj).
All objects can be made to be dependant on data fields for objects within tables. This means that if you associate an object with a field that contains multi-values, this object will be repeated (downwards through the table from its point of placement) for each occurrence of a value within the dependant field.
Data aware objects (text boxes, check boxes, selection boxes and radio buttons) should not be specified as being dependant on themselves as the assignment of a data aware field to a multi-valued data item will resolve that the object repeats naturally for values within its associated field.
You must specify a field position associated with one of the common block data items (sysdata, syshidden, sysperm) here by using the common addressing for of these items (1-9999/s1-s9999/p1-p9999). The dependant field position may also be defined as being a DIRT tag.
DIRT tags are re-resolved for each iteration of the object as it is repeated through the multi-value list and the "sysbldval" common block item reflects the iteration number for development control. Subroutines (DIRT items or subroutine objects) are also called for each iteration of the multi-value count.
All data aware objects (text boxes, check boxes, selection boxes and radio buttons) must be linked to data carriers (sysid, sysdata, syshidden and sysperm) within the system. This linking allows the system to position the data that is captured into these data carriers within simple dynamic arrays.
The following options are available here:
| 0 | Assigns the data within the object to the sysid common block variable. This item should only contain a single value. The item is page stack based and is therefore stored at different page stack levels. |
| 1-9999 | Assigns the data within the object to the sysdata common block array. The position of storage within the dynamic array is equal to the integer used here. The item is page stack based and is therefore stored at different page stack levels. |
| s1-s9999 | Assigns the data within the object to the syshidden common block array. The position of storage within the dynamic array is equal to the integer used after the "s". The item is page stack based and is therefore stored at different page stack levels. |
| p1-p9999 | Assigns the data within the object to the sysperm common block array. The position of storage within the dynamic array is equal to the integer used after the "p". This item is global and is maintained regardless of page stack level. |
A specific value can be specified using a decimal point to separate the field from the value. Eg. 3.3 - will set the system up to store the object value within the third value of the 3rd field of the sysdata item, s10.2 will store the object value within the second value of the tenth field of the syshidden item.
The {{dictpos DIRT tag can be used here to link the field to a field position defined within a file dictionary.
Trigger types define the type of action that will be taken at the server after the page/form is submitted. Valid trigger types are:
| refresh | the page will be re-generated and sent back to the browser. |
| sub | A user defined database subroutine will be called as a trigger routine. This option requires a trigger option (below) to be set to the name of the catalogued trigger subroutine. The "trigger parameters" option (below) can be used to pass a parameter string to the trigger subroutine through the syssubparms common block variable. |
| page | A page (as specified within trigger option below) will be created and returned to the browser. The "page" option clears out most data carriers (sysid, sysdata, syshidden, sysreserved). Use the "next" trigger type if these data items are to be preserved in the next page. |
| next | As for "page" but retains the data stored within the data carriers. |
| previous | As for next, but generates the preceding page. sysdata is preserved. If the trigger parameter is set to "all", then sysid and syshidden will also be preserved. |
| lookup | <deprecated> This item has been removed from Version 3 and above. It exists solely as an import for compatibility purposes. Generates a page listing items as defined within a lookup definition (the syslookup object). The trigger option (below) must include the name of the lookup definition followed by "," and the field position into which the selection lookup item should be placed. The special case "lookupname,0" replaces the "sysdata" and "sysid" data carriers with a record associated with the selected lookup item. |
| back | This moves the user back through the page stack and a page is generated and sent to the browser. The page that is generated is defined as being the previous page on the page stack. This trigger operation is identical to the "sub - sysnavback" trigger operation. |
The trigger option is used in conjunction with the trigger type to specify the trigger operation.
Trigger parameters are used in conjunction with the "sub" trigger type. Trigger parameters are passed to the trigger subroutine with in the "syssubparms" common block item.
This element allows for the insertion of an in-line style for the object. In-line styles provide a convenient solution for small presentation changes for the object and override preceding style sheets or <font> elements.
Example text for inclusion within the "style" property.
font-size:16pt;font-color:blue;
You will need to review the CSS1 and CSS2 specifications for details related to
the Cascading Style Sheet standards. The standard is maintained by the World
Wide Web Consortium.
The style class element supports the component-based approach to presentation based on CSS style classes. Style sheet classes must be defined before they are used and are therefore generally defined within the <head> HTML element.
A simple style sheet class definition follows:
<head>
<style>
.myclass {font-color:black;font-decoration:none;}
</style>
</head>
The style class element should therefore contain the text:
myclass
This event element supports user-defined code to be run as the user accesses the object.
Event code should either contain a detailed in-line script or a function call to an already defined function. Page functions should be defined before they are used and are generally defined within the page <head> HTML element.
It is best to include function calls at this level to maximise code re-use and to reduce the possibility of special characters (", < and >) being used within complex in-line scripts.
More information can be obtained from the World Wide Web Consortium, MSDN Online and Netscape.
This event element supports user-defined code to be run as the user clicks the object.
This event element supports user-defined code to be run after the user has changed the text within the text box object.
This event element supports user-defined code to be run as the user leaves the object.
The text placed within this element will be included within the HTML tag. This allows for the insertion of HTML attributes not handled directly by the page builder.
Specifies whether the object will be visible on the page when rendered.