| Oracle® Fusion Middleware Idoc Script Reference Guide 11g Release 1 (11.1.1) E10726-01 |
|
 Previous |
 Next |
Home > Idoc Script Reference Guide > Idoc Script Application > Idoc Script Uses
| Oracle® Fusion Middleware Idoc Script Reference Guide 11g Release 1 (11.1.1) E10726-01 |
|
Previous |
Next |
Home > Idoc Script Reference Guide > Idoc Script Application > Idoc Script Uses
There are six basic uses for Idoc Script:
Includes enable you to reuse pieces of Idoc Script and HTML code.
Variables enable you to define and substitute variable values.
Functions enable you to perform actions, including string comparison and manipulation routines, date formatting, and ResultSet manipulation.
Conditionals enable you to evaluate if and else clauses to include or exclude code from an assembled page.
Looping enables you to repeat code for each row in a ResultSet that is returned from a query.
The Administration Interface enables you to use Idoc Script in Content Server applets and customizations.
An include defines pieces of code that are used to build the Content Server web pages. Includes are defined once in a resource file and then referenced by as many template files as necessary. The system leverages includes very heavily.
Includes make it easier for you to customize your instance using component architecture and dynamic server pages. For more information on includes and customization, see the Oracle Fusion Middleware Developer's Guide for Content Server.
An include is defined in an HTM resource file using the following format:
<@dynamichtml name@> code <@end@>
An include is called from an HTM template file using the following Idoc Script format:
<$include name$>
Includes can contain Idoc Script and valid HTML code, including JavaScript, Java applets, cascading style sheets, and comments.
Includes can be defined in the same file as they are called from, or they can be defined in a separate file.
Standard includes are defined in the ucm_home_dir/idc/resources/core/idoc/std_page.idoc file.
HDA and CFG files are not script enabled, therefore using an include statement in either of these types of files is not supported.
See the following sections for more information:
One of the most common includes is the body definition element <@dynamichtml body_def>. This include sets the page background color, the color of hyperlinks, and the background image. The following is an example of code located in the ucm_home_dir/idc/resources/core/idoc/std_page.idoc file:
<@dynamichtml body_def@>
<!--Background image defined as part of body tag--->
<body
<$if background_image$>
background="<$HttpImagesRoot$><$background_image$>"
<$elseif colorBackground$>
bgcolor="<$colorBackground$>"
<$endif$>
<$if xpedioLook$>
link="#663399" vlink="#CC9900"
<$else$>
link="#000000" vlink="#CE9A63" alink="#9C3000"
<$endif$>
marginwidth="0" marginheight="0" topmargin="0" leftmargin="0"
>
<@end@>
Most of the standard template resource files (for example, ucm_home_dir/idc/resources/core/templates/pne_home_page.htm) contain the following Idoc Script code near the top of the page:
<$include body_def$>
When the Content Server resolves a template page containing this code, it looks for the <@dynamichtml body_def@> definition and replaces the placeholder code with the code in the definition.
The super tag is used to define exceptions to an existing include. The super tag tells the include to start with an existing include and then add to it or modify using the specified code.
The super tag uses the following syntax:
<@dynamichtml my_resource@>
<$include super.my_resource$>
exception code
<@end@>
You can use the super tag to refer to a standard include or a custom include. The super tag incorporates the include that was loaded last.
You can specify multiple super tags to call an include that was loaded earlier than the last version. For example, to make an exception to the standard body_def include in two different components, you can use the following syntax in the one that is loaded last:
<$include super.super.body_def$>
|
Caution: If you use multiple super tags in one include, ensure that you know where the resources are loaded from and the order they are loaded in. |
The super tag is particularly useful when making small customizations to large includes or when you customize standard code that is likely to change from one software version to the next. When you upgrade to a new version of Content Server, the super tag ensures that your components are using the most recent version of the include, modifying only the specific code you require to customize your instance.
In this example, a component defines the my_resource include as follows:
<@dynamichtml my_resource@>
<$a = 1, b = 2$>
<@end@>
Another component that is loaded later enhances the my_resource include using the super tag. The result of the following enhancement is that a is assigned the value 1 and b is assigned the value 3:
<@dynamichtml my_resource@>
<$include super.my_resource$>
<!--Change "b" but not "a" -->
<$b = 3$>
<@end@>
A variable enables you to define and substitute variable values.
The following sections describe how to work with Idoc Script variables:
Idoc Script variables are created in one of the following ways:
Many variables are predefined.
You can define your own custom variables.
Some variable values must be generated using queries and services. Some variable information is not automatically available from the database, so it must be asked for by defining a query and service.
See Chapter 3, "Master List: Idoc Script by Type" for more information on the types of Idoc Script variables.
You can reference a variable in templates and other resource files with the following Idoc Script tag:
<$variable_name$>
A value can be assigned to a variable using the structure:
<$variable=value$>
For example, <$i=0$> assigns the value of 0 to the variable i.
Variable values can also be defined in an environment resource (CFG) file using the following name/value pair format:
variable=value
For example, standard configuration variables are defined in the IntradocDir/config/config.cfg file.
Idoc Script supports multiple clauses separated by commas in one script block.
For example, you can use <$a=1,b=2$> rather than two separate statements: <$a=1$> and <$b=2$>.
The following structure can be used to evaluate the existence of a variable:
<$if variable_name$>
If the variable is defined, this conditional is evaluated as TRUE. If the variable is not defined or it is defined as an empty (null) string, it is evaluated as FALSE.
See "Conditional Example" for an example of how this type of reference is typically used.
When a variable value is required to fulfill a service request, the data cached in the DataBinder is evaluated in the following default order:
LocalData
Active ResultSets
Non-active ResultSets
Environment
For more information on the DataBinder, see the Oracle Fusion Middleware Developer's Guide for Content Server.
A regular variable that does not have special evaluation logic (such as Conditional Dynamic Variables) is equivalent to using the #active keyword prefix.
For example, the tag <$variable$> is equivalent to <$#active.variable$>. However, if #active is not explicitly stated and the variable is not found, an error report is printed to the debug output.
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.
See "Global Functions" for a list of Idoc Script functions.
Personalization functions refer to user properties that are defined in personalization files, also called user topic files. Each user's User Profile settings, personal links in the left navigation bar, and workflow in queue information are all defined in user topic files, which are HDA files located in the ucm_home_dir/data/users/profiles/us/username/ directories.
The following global functions reference user topic files:
For example, the Portal Design link in a user's left navigation bar is generated from the following code in the pne_nav_userprofile_links include (located in the ucm_home_dir/shared/config/resources/std_page.htm resource file). If the portalDesignLink property in the ucm_home_dir/data/users/profiles/us/username/pne_portal.hda file is TRUE, the link is displayed:
<$if utGetValue("pne_portal", "portalDesignLink") == 1$>
<$hasUserProfileLinks=1$>
<tr>
<td colspan=2 nowrap align="left">
<a class=pneLink href="<$HttpCgiPath$>?IdcService=GET_PORTAL_PAGE&Action=GetTemplatePage&Page=PNE_PORTAL_DESIGN_PAGE">
<$lc("wwPortalDesign")$></a>
<td>
</tr>
<$endif$>
A conditional enables you to use if and else clauses to include or exclude code from an assembled page.
Use the following Idoc Script keywords to evaluate conditions:
Conditional clauses use this general structure:
<$if conditionA$>
<!--Code if conditionA is true-->
<$elseif conditionB$>
<!--Code if conditionB is true-->
<$else$>
<!--Code if neither conditionA nor conditionB are true-->
<$endif$>
A condition expression can be any Idoc Script function or variable.
See "Referencing a Variable in a Conditional" for more information.
Boolean Operators can be used to combine conditional clauses. For example, you can use the and operator as follows:
<$if UseBellevueLook and isTrue(UseBellevueLook)$>
If the condition expression is the name of a ResultSet available for inclusion in the HTML page, the conditional clause returns true if the ResultSet has at least one row. This ensures that a template page presents information for a ResultSet only if there are rows in the ResultSet.
A conditional clause that does not trigger special computation is evaluated using the XXXXXXXXXXXX_cannot_cross-reference to a marker on a para in a bable_XXXXXXXXXXXXXX prefix. The result is true if the value is not null and is either a nonempty string or a nonzero integer.
See "Conditional Example" for an example of conditional code.
In this example, a table cell <td> is defined depending on the value of the variable xDepartment:
<$if xDepartment$>
<td><$xDepartment$></td>
<$else$>
<td>Department is not defined.</td>
<$endif$>
<$xDepartment=""$>
If the value of xDepartment is defined, then the table cell contains the value of xDepartment.
If the value of xDepartment is not defined or is an empty (null) string, a message is written as the content of the table cell.
The last line of code clears the xDepartment variable by resetting it to an empty string.
Loop structures allow you to execute the same code a variable number of times. Looping can be accomplished in two ways with Idoc Script:
See "Ending a Loop" for information on exiting and ending a loop structure.
ResultSet looping repeats a set of code for each row in a ResultSet that is returned from a query. The name of the ResultSet to be looped is specified as a variable using the following syntax:
<$loop ResultSet_name$>
code
<$endloop$>
The code between the <$loop$> and <$endloop$> tags is repeated once for each row in the ResultSet.
When inside a ResultSet loop, you can retrieve values from the ResultSet using the getValue function. Substitution of values depends on which row is currently being accessed in the loop.
When inside a ResultSet loop, that ResultSet becomes active and has priority over other ResultSets when evaluating variables and conditional statements.
You cannot use the <$loop$> tag to loop over a variable that points to a ResultSet. Instead you must loop over the ResultSet manually using the rsFirst and rsNext functions.
For example, you cannot use the following code to loop over a ResultSet:
<$name="SearchResults"$>
<$loop name$>
<!--output code-->
<$endloop$>
Instead, you must use the following code:
<$name="SearchResults"$>
<$rsFirst(name)$>
<$loopwhile getValue(name, "#isRowPresent")$>
<!--output code-->
<$rsNext(name)$>
<$endloop$>
In this example, a search results table is created by looping over the SearchResults ResultSet, which was generated by the GET_SEARCH_RESULTS service.
<$QueryText="dDocType <matches> 'ADACCT'"$>
<$executeService("GET_SEARCH_RESULTS")$>
<table>
<tr>
<td>Title</td><td>Author</td>
</tr>
<$loop SearchResults$>
<tr>
<td><a href="<$SearchResults.URL$>"><$SearchResults.dDocTitle$></a></td>
<td><$SearchResults.dDocAuthor$></td>
</tr>
<$endloop$>
</table>
While looping enables you to create a conditional loop. The syntax for a while loop is:
<$loopwhile condition$>
code
<$endloop$>
If the result of the condition expression is true, the code between the <$loopwhile$> and <$endloop$> tags is executed.
After all of the code in the loop has been executed, control returns to the top of the loop, where the condition expression is evaluated again.
If the result is true, the code is executed again.
If the code if the result is false, the loop is exited.
In this example, a variable named abc is increased by 2 during each pass through the loop. On the sixth pass (when abc equals 10), the condition expression is no longer true, so the loop is exited.
<$abc=0$>
<$loopwhile abc<10$>
<$abc=(abc+2)$>
<$endloop$>
You can use Idoc Script in several areas of the administration interface, including:
In the Workflow Admin tool, you can use Idoc Script to define the following:
step events
jump messages
extra exit conditions
tokens
custom effects for jumps
For example, the following step entry script sends documents in the Secure security group to the next step in the workflow:
<$if dSecurityGroup like "Secure"$>
<$wfSet("wfJumpName", "New")$>
<$wfSet("wfJumpTargetStep", wfCurrentStep(1))$>
<$wfSet("wfJumpEntryNotifyOff", "0")$>
<$endif$>
See "Workflows" for more information.
In the Web Layout Editor, you can use Idoc Script in the page titles, page descriptions, URL descriptions, query result pages, and content queries.
For example:
You can use Idoc Script tags in the query results page definition to specify the contents of each row in a search results table.
To set the search results to return all content items up to 7 days, you could define the search query to be:
dInDate > '<$dateCurrent(-7)$>'
To define a report that returns results based on the current user, you could define User Name is <$UserName$> as part of the report query expression.
See the Oracle Fusion Middleware System Administrator's Guide for Content Server for more information.
In the Batch Loader, you can use Idoc Script in a mapping file, which tells the BatchBuilder utility how to determine the metadata for file records. See the Oracle Fusion Middleware System Administrator's Guide for Content Server for more information.
In Archiver, you can use Idoc Script in the following areas:
Export query values. For example, to archive content more than one year old, you could use <$dateCurrent(-365)$> as the Release Date value.
Value map output values. For example, to set the expiration date one week in the future for all imported revisions, you could use <dateCurrent(7)$> as the Output Value.
See the Oracle Fusion Middleware System Administrator's Guide for Content Server for more information.
When you set values in the System Properties utility, in the Admin Server, or in the Local Configuration or Shared Configuration screens of the Inbound Refinery, you are actually setting Idoc Script configuration variables. See the documentation for these applications for more information.
