OScript Modules

There is a Content Server module created for each of the main functional areas of Content Server. Modules are Designed To:

?Make it easy to install, remove and upgrade customizations

?Decrease development time

There is a Kernel module on which all other modules depend and it contains core Content Server code and does not appear in the Install Modules page

There is a set of core modules that are automatically installed when you install Content Server

There are optional modules written by OpenText, third party developers, and other CSide users

A Content Server module must have:

• An initialization (INI) file
• An OSpace in a directory named ospace, containing subclasses of certain objects

A Content Server module may have:

• Additional OSpaces, in order to split up functionality
• WebLingo files (HTML with embedded OScript)
• Web support files (.gif, .class, .jar, .cab, etc.)
• Documentation (mostly empty, but it can be used for documentation)
• Web help and adminhelp files (a set of HTML files and toc.txt file)
• Properties files (used for localizing a module’s user text when it needs to be displayed in multiple languages)

1. The INI file is created by a special method in the module’s WebModule object, which stores all the key information about the module.
2. The module’s Configure request handler performs the actual installation, uninstallation, and upgrade of a module. When a module is installed, its directory is moved to the module directory from the staging directory. Its support directory is moved to the support directory of the Content Server installation.
3. The Modules section of the opentext.ini file (located in the config folder) is modified to include the information needed for the new module during Content Server startup. What else happens depends upon how the module was configured: The module may alter the database schema and/or add data to the database. (Dont try this as a novice!!!)
4. All installed modules are found in the modules directory and in the core directory of the Content Server installation.
5. If a module’s name is listed in the“Installable Modules” portion of the Install Modules page, then the module’s directory of files is in the Content Server installation’s staging directory.

OSpaces

When you want to customize Content Server’s objects, create a new OSpace.

?objects that contain new functionality

?objects that are meant to extend or override existing objects

When you make a module, you create an OSpace for the module’s objects.

OSpace setup

• When a feature is added to an object, the children of the object automatically inherit the feature.
• When a feature is modified, its descendants automatically inherit the modifications.
• When an inherited feature is deleted, its value is cleared and a new value is automatically re-inherited from its parent. (This is a good way to cancel modifications to a feature.)
• When a new feature is deleted, it is deleted for all descendants of the object, regardless of whether the feature has been modified by one of the descendants.

Calling an object in a different OSpace

If you want to call an object's features from other objects, you can either create a global reference to it in your OSpace's Globals object, or refer to it directly by its fully qualified name. The latter is slightly faster at runtime, and allows the compiler to perform type checking, while the former is the only way to refer to temporary objects from any location.

Every OSpace is created with a Globals object. This object is bound to a global variable by the default start-up script, allowing the object and any of its features to be accessed anywhere using the syntax:

$GlobalName.featureName

Each OSpace includes a Globals object. The Globals object serves as a registry for objects within that OSpace which might need to be accessed from any object or script in Content Server. A Globals object is automatically created when you create an OSpace.

• When an OSpace opens, the root object's Startup method is automatically executed. This method calls other methods, one of which initializes the Globals object and creates a global variable for the object.
• See the root and the globals object:

$GlobalName.featureName

p.Ex $answerdesk.Documentation adresses this object