Each HDA file contains a header line and one or more sections. The header line identifies the Content Server version, character set, and Java encoding for the HDA file. If an HDA file contains double-byte (Asian language) characters, the correct character set and encoding must be specified so that Content Server can read the file properly. The header line is not required for single-byte characters, but it is a good practice to include it in your HDA files.

Two types of sections, Properties and ResultSet, are relevant to component development. These sections are used to define the properties of the file (name, location, and so on) and the ResultSet, which defines a table or columns and rows of data. A ResultSet often represents the results of a query. All other sections tags are for internal application use only.

Comments are not allowed within a section of an HDA file. However, you can place comments in the HDA file before the first section, between sections, or after the last section. Blank lines within a section of an HDA file are interpreted as a NULL value. Blank lines before the first section, between sections, or after the last section are ignored. None of the section types are mandatory in an HDA file, so unused sections can be deleted.

• The Properties section contains a group of name/value pairs. For a custom component, the most common name for a Properties section is LocalData, which means that the name/value pairs are valid only for the current HDA file.

  You can also define global name/value pairs in a Properties section called Environment, but this section is rarely used. The recommended practice is to define global environment variables in a configuration file, such as config.cfg.

  {Example - Properties Section of an HDA File } shows a Properties section from an HDA file.

  Properties Section of an HDA File
  @Properties LocalData
  PageLastChanged=952094472723
  LocationInfo=Directory,Public,
  IsJava=1
  refreshSubMonikers=
  PageUrl=/intradoc/groups/public/pages/index.htm
  LastChanged=-1
  TemplatePage=DIRECTORY_PAGE
  IdcService=PAGE_HANDLER
  LinkSelectedIndex=0
  PageName=index
  HeaderText=This is a sample page.  The Page Name must remain index.  The Page Properties for this index page should be customized.
  PageFunction=SavePage
  dSecurityGroup=Public
  restrictByGroup=1
  PageType=Directory
  PageTitle=Content Server Index Page
  @end

• Each ResultSet section of an HDA file defines a table or columns and rows of data. A ResultSet can be used to pass information to a database or to represent the result of a database query. A ResultSet section has the following structure:

  • The first line defines the name of the ResultSet table, using the format @ResultSet resultset_name.

  • The second line defines the number of columns.

  • The next n lines define the column names.

  • The remaining lines define the values in each cell of the table.

  • The last line of the section ends the table, using the format @end.

  {Example - ResultSet Section of an HDA File} shows a ResultSet called Scores that has 4 columns and 3 rows.

  ResultSet Section of an HDA File
  @ResultSet Scores
  4
  name
  match1
  match2
  match3
  Margaret
  68
  67
  72
  Sylvia
  70
  66
  70
  Barb
  72
  71
  69
  @end

  The following table shows the ResultSet data in a columnar form. A ResultSet can be given any name.

  name	match1	match2	match3
  Margaret	68	67	72
  Sylvia	70	66	70
  Barb	72	71	69

  Content Server uses some predefined ResultSets with the following names, which should not be used for the custom component table.

  ResultSet Name	Location	Purpose
  Components	IntradocDir/data/components/ idcshort-product-id_components.hda	Defines the name and location of any custom components you have created. You must specify the short product ID (cs, ibr, urm) for short-product-id.
  IntradocReports	IdcHomeDir/resources/core/reports/ reports.hda	Specifies the default report templates for Content Server.
  IntradocTemplates	IdcHomeDir/resources/core/templates/ templates.hda	Specifies all of the default templates for Content Server (except for search results and report templates).
  ResourceDefinition	DomainHome/ucm/short-product-id/custom/ component_name/component_name.hda	Defines resources for a custom component.
  SearchResultTemplates	IdcHomeDir/resources/core/templates/ templates.hda	Specifies the default search results templates for Content Server.

The idcshort-product-id_components.hda file is a text file that tells Content Server which components are enabled and where to find the definition file for each component.

The idcshort-product-id_components.hda file is always stored in the IntradocDir/data/components/ directory. You can use Component Wizard, Component Manager, or ComponentTool to make changes to this file if needed.

{Example - idccs_components.hda File for Multiple Enabled Components} shows an idccs_components.hda file that lists several enabled components, such as schema, configuration migration, and SOAP components.

idccs_components.hda File for Multiple Enabled Components
@properties LocalData
blDateFormat=M/d/yy 
@end
@ResultSet Components
2
name
location
SchemaDCL
custom/SchemaDCL/SchemaDCL.hda
ConfigMigrationUtility
custom/ConfigMigrationUtility/Cmu.hda
Soap
custom/Soap/Soap.hda
@end

A component definition file points to the custom resources that you have defined. This file specifies information about custom resources, ResultSets, and merge rules. Because it serves as the "glue" that holds a component together, the component definition file is sometimes called the glue file.

The definition file for a component is typically named component_name.hda, and it is located in the DomainHome/ucm/short-product-id/custom/component_name/ directory.

The @Properties LocalData section in an HDA file maps to the LocalData category of the data binder. The LocalData information consists of name/value pairs.

LocalData information is maintained only during the lifetime of the Content Server request and response. Unlike information about the server environment, which rarely changes, the LocalData information for each request is dynamic.

From the point of view of an HTTP request, the initial LocalData information is collected from the REQUEST_METHOD, CONTENT_LENGTH, and QUERY_STRING HTTP environment variables. As the service request is processed, the LocalData name/value pairs can be added and changed.

Each @ResultSet section of an HDA file maps to a named result in the DataBinder object. Some ResultSet can be made active, taking precedence over other ResultSets during a value search. A ResultSet becomes active when the ResultSet is looped on during page assembly. An active ResultSet take precedence over any other ResultSets during a value search of the DataBinder object. When a service request requires data and the value is not found in the LocalData or an active ResultSet, the remaining ResultSets (those that are not active) are searched next.

Environment values are placed in the DataBinder object as name/value pairs, which are defined in configuration files such as IntradocDir/config/config.cfg, intradoc.cfg, and environment-type resource files.

You can add customized files for your site to change the look or actions of Content Server. For example, the following types of files are often referenced in custom resources:

• Graphics

  Replace the icons, backgrounds, and logos that constitute the standard Content Server interface.

• Help

  With the assistance of Consulting Services, you can customize help files for your content management system.

• Classes

  Java code can change or extend the functionality of Content Server. Java class files must be packaged into directories for placement in the DomainHome/ucm/short-product-id/classes/ directory.

A component ZIP file contains all files that define a Content Server component. It can be unpackaged to deploy the component on other Content Server instances.

When you define one or more custom installation parameters, several additional files are created in addition to the files that compose the basic component file structure.

If installation parameters are created for the component, then during the component installation process the component installer automatically places two files in the directory for the component within the data/components/ directory. These files hold the preference data as follows:

• The config.cfg file: Contains the parameters that can be reconfigured after installation.

• The install.cfg file: Contains the preference data definitions and prompt answers.

• Backup ZIP file: A backup file that is created if the component is currently installed and is being reinstalled.

A ResourceDefinition ResultSet consists of four columns:

• The type column defines the resource type, which must be one of the following values:

  • resource, which points to an HTML include (HTM), string (HTM), dynamic table (HDA), or static table (HTM) resource file.

  • environment, which points to an environment resource (CFG) file.

  • template, which points to a template resource (HDA) file.

  • query, which points to a query resource (HTM) file.

  • service, which points to a service resource (HTM) file.

• The filename column defines the path and file name of the custom resource file. This can be an absolute path or a relative path. Relative paths are relative to the DomainHome/ucm/short-product-id/custom/component_name/ directory.

• The tables column defines the ResultSet tables to be loaded from the resource file. ResultSet names are separated with a comma. If the resource file does not include ResultSets, this value is null. For example, HTML include resources do not include table definitions, so the value for the tables column is always null for an HTML include file.

• The loadOrder column defines the order in which the resource is loaded. Resources are loaded in ascending order, starting with resources that have a loadOrder of 1. If multiple resources have the same loadOrder, the resources are loaded in the order they are listed in the ResourceDefinition ResultSet. If there are multiple resources with the same name, the last resource loaded is the one used by the system. Normally, you should set loadOrder to 1, unless there is a particular reason to always load one resource after the others.

A MergeRules ResultSet consists of three columns:

• The fromTable column specifies a table that was loaded by a custom resource and contains new data to be merged with the existing data. To properly perform a merge, the fromTable table must have the same number of columns and the same column names as the toTable table.

• The toTable column specifies the name of the existing table into which the new data is merged. Usually, the toTable value is one of the standard Content Server tables, such as IntradocTemplates or QueryTable.

• The column column specifies the name of the table column that Content Server uses to compare and update data.

  • Content Server compares the values of column in fromTable and toTable. For each fromTable value that is identical to a value currently in toTable, the row in toTable is replaced by the row in fromTable. For each fromTable value that is not identical to a value currently in toTable, a new row is added to toTable and populated with the data from the row of fromTable.

  • The column value is usually name. Setting this value to null defaults to the first column, which is generally a name column.