This chapter describes the different types of Idoc Script variables and functions, and groups the variables and functions by type.
Some dynamic variables are conditional and can only be used within a conditional statement such as if, while, elseif, or loop. These variables have the following special features:
Conditional variables are internal flags that are gettable but not settable.
Conditional variables will only provide a Boolean response and do not return a value such as a string or integer.
Conditional variables will not accept the #active keyword prefix. Thus, an error report is printed to the debug output if the variable is not found.
The following is a list of Idoc Script conditional dynamic variables.
Configuration variables are predefined Idoc Script variables that are generally used as settings in configuration files. These variables can be used within Idoc Script to detect whether a configuration setting is enabled or to return the value of the configuration setting.
Configuration variables that pass a Boolean value can be set only to the value TRUE (1) or FALSE (0).
Unless otherwise specified, Boolean-type configuration values default to FALSE (0), and string-type configuration values default to an empty string.
This section lists the configuration variables by the configuration file (typically .cfg or .hda) in which they are most commonly located. Your actual application will vary depending on the criteria and selections made during installation.
Section 3.2.1, "Oracle Content Server Configuration Variables"
Section 3.2.6, "Record Manager and Retention Manager Configuration Variables"
The following configuration files are located in these configuration directories.
The following configuration variables are located in the DomainHome/ucm/cs/bin/intradoc.cfg file. These variables define directory paths and global settings for the Oracle Content Server system and Admin Server.
The following configuration variables are located in the IntradocDir/config/config.cfg file. These variables define instance settings for the Admin Server and most of the configuration settings for the Oracle Content Server system.
The following configuration variables are located in the folders_environment.cfg file in the IdcHomeDir/components/folders_g/ directory. These variables define settings for Oracle Content Server folders.
The following configuration variables are located in the provider.hda file in the IntradocDir/data/providers/provider_name/ directory. These variables define settings for Oracle Content Server providers.
The following variables are used to configure the Content Tracker application.
The following configuration files are located in the Inbound Refinery installation directory (noted by IntradocDir/config/config.cfg).
Configuration variables returning a string that defines a directory or file path related to the Inbound Refinery will return that path relative to the Inbound Refinery installation directory. These paths are generally not recognizable to the Oracle Content Server system nor usable to the user if passed as information within an HTM page.
The following variables are used to configure the Link Manager application. These variables are set in the IntradocDir/ucm/cs/bin/config.cfg file.
The following variables are used to configure the Pop-Up Calendar application. These variables are set in the IntradocDir/config/config.cfg file.
The following variables are used to configure the Record Manager and Retention Manager applications. These variables are set in the IntradocDir/ucm/urm/bin/config.cfg file.
A dynamic variable is evaluated on each occurrence of the variable. Thus, each time the variable is encountered the value is recalculated from code. (In contrast, a value variable is evaluated once at the beginning of the service call and that value is used throughout the service call. See Section 3.9, "Value Variables.") Dynamic variables generally return a value such as a string or an integer.
The following is a list of Idoc Script dynamic variables.
Web server variables are the CGI environment variables that are set when the server executes the gateway program. In order to pass data about the information request from the server to the script, the server uses command-line arguments and environment variables. These environment variables can be used to output information to a log file or can be used within Idoc Script statements and as part of evaluations.
For example, this Idoc Script statement evaluates whether the remote host address matches a specific string:
<$if strEquals("207.0.0.1",REMOTE_HOST)$>
This HTML and Idoc Script markup displays a list of web server environment information on the page:
<P>HTTP_INTERNETUSER=<$HTTP_INTERNETUSER$></P> <P>REMOTE_HOST=<$REMOTE_HOST$></P> <P>SCRIPT_NAME=<$SCRIPT_NAME$></P>
The following is a list of web server variables.
Idoc Script has many built-in global functions. Functions perform actions, including string comparison and manipulation routines, date formatting, and ResultSet manipulation. Some functions also return results, such as the results of calculations or comparisons.
Information is passed to functions by enclosing the information in parentheses after the name of the function. Pieces of information that are passed to a function are called parameters. Some functions do not take parameters; some functions take one parameter; some take several. There are also functions for which the number of parameters depends on how the function is being used.
The following is a list of Idoc Script global functions.
Page variables are set on a particular web page to enable specific page attributes or functionality. A page variable applies only to the page on which it is set.
This section includes the following topics:
Page variables that affect page display are typically set near the top of the page. Page display variables should be used as read-only variables; setting or changing the value of any of these variables will typically change the way all metadata is displayed on the page, which in most cases is not the desired effect.
The following is a list of Idoc Script page display variables.
Field display variables can be grouped into the following types:
The following variables define information about a metadata field. The variable values are loaded or computed for each metadata field.
The std_prepare_metafield_include include in the resource file named IdcHomeDir/resources/core/std_page.htm loads a number of field information variables from the local data in preparation for displaying the current metadata field.
<@dynamichtml std_prepare_metafield_include@> <!--Prepare for presenting field--> <$fieldName=dName, fieldCaption=dCaption, fieldDefault=dDefaultValue$> <$fieldType=dType, fieldIsOptionList=dIsOptionList, fieldOptionListType=dOptionListType$> <@end@>
There are several commonly used page variables that affect the display of metadata fields. These variables can be set using different syntaxes at different places on a page, depending on how they are being used.
The following formats can be used to set a special field display variable:
Name/Value pair: The variable is set using the standard variable=value format. For example, isHidden=1. This format is typically used to set the display of the current metadata field at the point in the page where the field is being generated by looped code.
FieldName:Variable format: The variable is set by defining it as a parameter for the metadata field it applies to. For example, myMetadata:isHidden. This format is typically used at the top of a page to set the global display of a particular metadata field.
If a common field display variable is set at the top of a template page, it should be placed before the <HEAD> tag. Placing the variable in or after the <HEAD></HEAD> section will result in the field being displayed (or not displayed) as you intended, but the JavaScript validation code in the header will still be evaluated, so an … is not an object error will be thrown when you attempt to display a checkin page.
The following is a list of the common field display variables.
If these common field display variables are not sufficient to provide the required flexibility, the entire implementation of a metadata field can be replaced by setting the field variable to the name of a resource include that should be used instead (for example, myField:include=customInclude).
The standard implementation is referred to by the variable defaultFieldInclude , whose value is different depending on whether the field is being generated on a checkin/update, query, or info page. It also varies considerably based on the type of field being displayed. If the standard field include is overridden, then the new implementation must take into consideration all the issues of the different pages, including JavaScript validation and the Upload applet.
Use this approach only as a last resort. It is preferable to extend existing functionality and set local variables to have custom functionality.
include tag in this way to insert custom HTML code for a special metadata field, you must place the include statement after the </HEAD> tag on the page. If you place it before the </HEAD> tag, the system will insert your custom HTML code into the header and attempt to read it as JavaScript.A number of other variables are available to affect the display of metadata fields. Generally, these are used to define the display of a metadata field depending on which field is currently being generated and the value of related common field display variables. The following is a list of other field display variables.
This example shows how the compute_std_field_overrides include in the IdcHomeDir/resources/core/templates/std_page.htm resource file determines if the field currently being generated is hidden, information only, excluded, and/or relocated. This code is looped over during generation of each metadata field on a page.
<@dynamichtml compute_std_field_overrides@>
<$isCustomHidden = getValue("#active", fieldName & ":isHidden")$>
<$if isHidden or isCustomHidden$>
<$isFieldHidden = 1$>
<$else$>
<$isFieldHidden = ""$>
<$endif$>
<$isCustomInfo = getValue("#active", fieldName & ":isInfoOnly")$>
<$if isInfo or isCustomInfo or isFieldHidden or isInfoOnly$>
<$isFieldInfoOnly = 1$>
<$else$>
<$isFieldInfoOnly = ""$>
<$endif$>
<$isCustomExcluded = getValue("#active", fieldName & ":isExcluded")$>
<$isCustomRelocated = getValue("#active", fieldName & ":isRelocated")$>
<$if isCustomExcluded or (isCustomRelocated and not isRelocated) or isExcluded or (isFieldHidden and not isFormSubmit)$>
<$isFieldExcluded = 1$>
<$endif$>
<@end@>
Read-only variables can be used to gather information about the current template, the user who is currently logged in, or other current settings. These variables are read-only and cannot be assigned a value.
Template-related read-only variables make it possible to create conditional content in a template based on the identity of the template. These pre-defined variables allow you to display the class, file path, name, or type of any template on an Oracle Content Server web page. This is particularly useful while you are developing your Web site.
The following read-only variables are related to templates.
In this example, the internal name of the template appears under the Administration link in the left sidebar of all Oracle Content Server web pages. To accomplish this change, the pre-defined TemplateName variable was added to the pne_nav_admin_links include that defines the Administration links.
The following is an example of using the TemplateName pre-defined variable to display the internal template name on a web page.
<$if IsSubAdmin$>
<tr>
<td>
<a href="<$HttpCgiPath$>?IdcService=GET_ADMIN_PAGE&Action=
GetTemplatePage&Page=ADMIN_LINKS"
OnMouseOver="imgAct('admin')"
OnMouseOut="imgInact('admin')">
<img src="<$HttpImagesRoot$>
<$button_admin_grey_ish_image$>" width="<$navImageWidth$>" height="<$navImageHeight$>" name="admin" border="0" alt="<$lc("wwProductAdministration", ProductID)$>"></a>
</td>
<td>
<a class=pneHeader href="<$HttpCgiPath$>?IdcService=GET_ADMIN_
PAGE&Action=GetTemplatePage&Page=ADMIN_LINKS"
OnMouseOver="imgAct('admin')"
OnMouseOut="imgInact('admin')">
<$lc("wwAdministration")$></a>
</td>
</tr>
<tr>
<td colspan=2><font color=#FFFFFF style="Arial"
size="-1"><$TemplateName$></font></td>
</tr>
<$endif$>
User-related read-only variables make it possible to gather information about the current user.
The following read-only variables are related to users.
One content-related read-only variable, "SourceID", makes it possible to retrieve the Content ID of the current dynamic server page.
This variable returns the same value as ref:dID. See Section 2.6.4, "Referencing Metadata in Dynamic Server Pages."
The following variable is set only as internal flags, so it can be retrieved but not set directly.
Setable variables can be set within script or used within a CGI string. For example, the variable "ScriptDebugTrace" can be used as a parameter to a service call to display debug trace information on a page. Setting one of these variables can change the content of the page.
The following is a list of Idoc Script setable variables.
Idoc Script includes predefined functions and variables that are used specifically for workflows.
Workflow Functions perform actions or return results relative to a workflow.
Workflow Variables enable you to set values for variables related to workflows.
For a detailed description of how workflows are implemented in Oracle Content Server, see Oracle Fusion Middleware Application Administrator's Guide for Content Server.
The following points summarize the use of Idoc Script in workflows:
Workflow jumps are initiated through the evaluation of Idoc Script that is defined for a particular step event (entry, update, or exit).
As a revision moves from step to step, the system creates a companion file that maintains information about the state of the revision in the workflow. Along with user-defined options, the system also maintains the history of what steps the revision has been to, the last entry time, and the number of times a revision has entered a particular workflow step.
Global state information is maintained as the revision moves from step to step.
Localized state information is stored with the step and becomes available when a revision is at that step.
The companion file uses keys to keep track of workflow state information. The syntax for a key is:
step_name@workflow_name.variable=value
For example, the following keys define the value of the entry count and last entry variables for the Editor step of a workflow called Marketing:
Editor@Marketing.entryCount=1
Editor@Marketing.lastEntryTs={ts '2002-05-28 16:57:00'}
All workflow script evaluation occurs inside a database transaction. The result is that any serious errors or aborts that are encountered cause no change to either the database or the companion file. This also means that no Idoc Script workflow function should take more than a negligible amount of time. Consequently, to trigger an external process, an Idoc Script function should be written to execute in a separate thread.
Caution:
If you are using Idoc Script or custom components to load workflow information into the local data, keep in mind that there is a risk of data pollution. This is particularly important if you are loading information for a different revision than the current one.Workflow functions perform actions or return results relative to a workflow. The following is a list of workflow functions.
Workflow variables are used to set values related to workflows. The following is a list of workflow variables.
A value variable is evaluated once at the beginning of a service call and that value is used throughout the service call. The variable is then reevaluated on each new service call. In contrast, a dynamic variable is evaluated on each occurrence of the variable. For example, the value variable isNew evaluates whether the content item is new or a revision when performing a check in. That evaluation is used throughout the call to the checkin service.
The following is a list of Idoc Script value variables.