Search Operations
EXEC_SRCH_PAGES Performs a free text search on the site's pages. The result takes the form of a HTML table, listing links to the pages. The result is held in a hzChain which is placed in an event variable called srch_pages_result. The number of links in the result listing is placed in an event variable called srch_pages_count. These values are accessed in the search response page (defined in the configs), by percent entities bearing these reserved names. Similarly, the search string is expected to be supplied in an event variable called srch_pages_criteria. This is the field name the search form, be it in a search page or part of a JavaScript popup, must use. Use of reserved names means the only parameter needed is the limit on number of records found.
EXEC_SEARCH This effects a free text search on documents. This requires the following paremeters:-
| format | Table to control output |
| m_Action | The value of event variable x-action must have (if specified) |
| m_Source | Source to search from (eg indiginous web pages) |
| m_Criteria | The field name containng the search criteria |
| m_Count | Name of the variable used to display the count |
| m_Found | Name of the variable used to display the result (chain of HTML of table defined in format) |
| m_nLimit | Max number of records to show |
File System Commands
EXEC_FILESYS File system commands direct the creation and deletion of directories and then save/delete files to/from those directories. These are added by the <filesys> tag which has 3 attributes, 'action' (command), 'resource' and 'content'. The operations allowed are:-
| 1) mkdir | Make a new directory |
| 2) rmdir | Remove a directory |
| 3) save | Save a binary data class member to a file |
| 4) delete | Save a binary data class member to a file |
The 'resource' specifies the single directory or file the command will operate on while when saving, the 'content' specifies what data is to be saved. Both the resource and content attributes anticipate percent entities.
System Admin Commands
EXEC_SETVAR Explicity set a user session standalone variable: There are three attributes, variable name, type and value.
EXEC_ADDUSER Create a user. Dissemino allows multiple types of user account to be defined, in addition to the standard webmaster/admin accounts. In a mail order company for example, there could be a customer account for customers to view their order history, view the status of orders in progress and place new orders. Then there could be an account for staff to do such things as monitor levels of stock, book holidays and claim expenses. Then there could be yet another account type for managers to do such things as manage rosters, re-order stock and run reports.
There are two means by which different user accounts can be implemented - By using different user classes and by status code. The former applies when different users need different sets of information. But where two account types differ mostly in access levels e.g basic vs premium access, the latter will suffice. Applications can use a mix of both.
Dissemino requires that usernames are unique, not just within any given user account type but across all user account types. All users have an entry in the subscriber reposotory as well as an entry in the respective user repository. The subscriber entries authenticate while the entries in the user repositories store all the other information.
The subscriber class always has the exact same set of following members:-
| 1) username | As a string even though it is commonly an email address. |
| 2) password | A string or an MD5 |
| 3) userUID | Unique user id (object id within subscribers) |
| 4) userAddr | User address (object id within the specific user repository) |
| 5) userType | Which user repository |
| 6) userStatus | User status e.g. Basic/Premium |
EXEC_LOGON Create a user session (hdsInfo instance) and set the session parameters to effect a login. This will have a single argument, namely the username. In the configs, this is usually a percent entity aimed at providing the username, e.g. %e:username;
EXEC_TEST Test if a condition is true (false is an error). Currently this is limited to testing if two values are equal. This may be used to test if a code which has been emailed as part of a user registration process, is equal to they expected value (which would typically have been held in a previously added session variable).
EXEC_EXTRACT Extract text from a submitted file (eg docx). There are two arguments, 'input' (name of field containing the file) and 'target' (name of the output variable).
Object Address and URL Convention
Object ids are the addresses of objects within repositories and are always 32-bit positive numbers. For an object to be retrieved, either for display or editing, the object id must be supplied somehow. The retrieval of data is effected, either by I-class percent entities operating on data objects in an object cache in-situ, or by V-class entities operating on a pre-loaded session object. In either case the object id is required. There are only two possible sources for the object id: In the special case where the applicable repository is the in-built subscriber repository and the object id is the subscriber id. In all other cases it is supplied as a resource argument - a part of the URL.
Any search on a repository will produce a bitmap of object ids in ascending order. If the objects found are in a cache repository, the list can be readily re-ordered and grouped by one or more members and presented by a more meaningful member such as title. The actual URL though, visible in the browser address window upon selection, will always be of the same form: It will be the URL of the page that presents objects of the class (with or without a form to edit the object), followed by the object id. Unless the URL conveys an object id, the object id will be 0 meaning NULL object, i.e. a blank form for the creation of a new object.
Complex Class Addressing
When an object is set up, it will have a target repository and have an object id - the address in the repository if assigned. It will also have a class. For a non-complex class the class setting can be ignored as it will always be that of the target repository. For a complex class this will not be the case in a form used to populate a sub-class instance.
Suppose we have repository rA which accepts objects of the complex class cA. If cA has a member with data type sub-class cB, two forms are involved, one for each data class. In the cA form the EXEC_OBJ_START command sets up a session object called keyA to have a target repository of rA. In the cB form the EXEC_OBJ_START command also uses keyA and rA, but the class will be cB. The object id will also differ as formB will have been reached by a URL giving the object id in a @resarg.
The different class delta id and object id will not confuse the session object as this is essentially a one to many mapping between hdbROMID instances and atomic values. hdbROMID comprises the class delta id, object id and member id.