7 Customizing Repository Fields and Metadata

This chapter provides information on managing repository content when there is a need to create custom application fields and custom metadata to tailor input forms and searching. You also can create metadata schemas to manage dependent lists that are localized for specific sites

This chapter includes the following topics:

• Understanding Custom Fields

• Defining an Option List

• Using Schemas to Customize Metadata

7.1 Understanding Custom Fields

Application fields are custom fields that you can use to customize forms and pages. With application fields, you can add features such as dependent lists to forms. You can also use application fields in custom components, HCSP (Hypertext Content Server page) files, and HCSF (Hypertext Content Server Form) files.

By default, application fields do not appear on the standard check-in and search forms, but are used by custom templates. You can use application fields as placeholders or with schema views to enable dependent lists without creating an associated metadata field. For more information, see Using Schemas to Customize Metadata.

You can specify in a content profile which application fields are displayed on the standard check-in and search pages. For more information, see Managing Content Profiles .

Application fields are not indexed and are not searchable. Changes to application fields do not affect the database or the index.

If you use the Electronic Signature component, you can also define custom fields for use with the electronic signature metadata. For more information on Electronic Signature, see Signing Content Electronically.

For each content item, the system maintains a set of information about the content, or metadata. Metadata is similar to a card in a library's card catalog, while the actual files are similar to library books. As with the card catalog, metadata consists of information about a file (title, reference number, author, subject, publishing date, book location, and so forth).

In addition to the standard metadata fields provided with the system, you can create new fields to accommodate unique content or system design requirements. It is important to create only the necessary amount of additional metadata necessary to help locate or manage a content item.

When you create a custom field name, the system automatically prefixes the name with an 'x' to ensure that it is unique and does not conflict with any reserved names. Similarly, when you create custom user information (metadata) fields, the system prefixes the name with a 'u' to ensure that it is also unique and does not conflict with any reserved names.

Metadata fields are indexed and searchable. Changes to custom metadata fields can affect the database (where information about metadata fields is stored) or the search index (where the metadata values are stored).

Note:

When using the DATABASE.METADATA search engine (the default value is SearchIndexerEngineName), there is no search index to manage or query. The data is stored and retrieved using the following tables: RevClasses, Revisions, DocMeta, and Documents.

This section covers the following topics:

• Standard Metadata Fields

• Adding or Editing a Custom Field

• Rebuilding the Database or the Search Index

7.1.1 Standard Metadata Fields

The following are standard fields provided with the system. You cannot edit or delete these fields.

Field Caption	Entry Method	Required?	Definition
Content ID	Text Entry or Automatic Generation	Yes	The unique identifier for each content item. Duplicate names are not allowed. Maximum field length is 30 characters. Use only letters, numbers, and underscores (_). Do not use spaces or other special characters. The Content ID can be automatically generated. For more information, see the General Options tab of the System Properties Utility. If using an Oracle or DB2 database, all Content IDs are converted to uppercase letters automatically.
Type	List	Yes	An identifier used to group content. Types become subdirectories in the weblayout directory. Maximum field length is 30 characters. Use only letters, numbers, and underscores (_). Do not use spaces or other special characters.
Title	Text Entry	Yes	A descriptive title for the content item. Maximum field length is 255 characters.
Author	List or Text Entry	Yes	The user who checked in the content item.
Security Group	List	Yes	The security group for which users must have permission to access the content item. Duplicate names are not allowed. Maximum field length is 30 characters. Use only letters, numbers, and underscores (_). Do not use spaces or other special characters.
Account	List or Text Entry	No	The account for which users must have permission to access the content item. This field is available only if accounts are enabled.
Primary File	Text Entry or Browse to File	Yes	The complete path to the native file being checked in. Maximum file name length is 80 characters, including the directory path and file extension. Maximum file extension length is eight characters. The Folders option modifies this maximum file name length on installation to 255 characters.
Alternate File	Text Entry or Browse to File	No	The path name to another Web-viewable file format of the native document, or one that can be converted to a Web-viewable format. For example, when checking in a FrameMaker or Quark document that has several files that comprise the document, you would check in a zipped file as the native format (or Primary File) and a Postscript, PDF, or viewable file as its Alternate File. The zipped file is not viewable on the Web, but Inbound Refinery converts the Postscript file to its Web-viewable format, PDF. Maximum file name length is 80 characters, including the directory path and file extension. Maximum file extension length is eight characters. The Folders option modifies this maximum file name length on installation to 255 characters.
Revision	Automatic Generation or Text Entry	Yes	A label (such as 1, 2, 3,... or A, B, C,...) that represents the number of times the content item has gone through its life cycle (the number of revisions). You can customize the Revision label for your revision scheme.
Comments (optional)	User Text Entry	No	A field for additional information about the file. Maximum field length is 255. This field is considered a custom field and can be deleted.
Release Date	Automatic Generation or Text Entry	Yes	The date the file is to be released so it is available for searching and viewing. The Release Date defaults to the date and time the file is checked in.
Expiration Date	Text Entry	No	The date the file is no longer available for searching or viewing. All revisions of the content item expire when the current revision expires. When a content item expires, revisions are retained, but only an administrator can access from the Repository Manager, unless you use Notification of Expiration.

7.1.2 Adding or Editing a Custom Field

To add or edit a custom field, either application or metadata field:

1. Use the main menu to choose Administration then Admin Applets.
2. Click Configuration Manager.
3. On the Configuration Manager page, click Information Fields to add a metadata field. Click Application Fields to add or edit an application field.

   Click Add to add a new field or highlight a field. Click Edit to change a field.

4. If you are adding a metadata field, enter the name. Duplicate names are not allowed. Maximum field length is 29 characters. Use only letters, numbers, and underscores (_). Do not use spaces or other special characters. Click OK when done.
5. On the Add/Edit Metadata Field page or Add/Edit Application Field page, enter or edit the information for the field:

   • Field Caption: The label for the field displayed to users.

   • Field Type: The size indicated is the character input length, not an indication of the actual number of bytes needed to store the field.

     • Integer: -2⁶³ to 2⁶³ -1. By definition, an integer is a natural number, so decimal values and commas are not permitted.

     • Decimal: -2³¹ to 2³¹ (-2 billion to +2 billion).

     • Memo: 2000 characters.

     • Date: Date format (such as dd/mm/yyyy or dd/mm/yy for the English-US locale).

     • Long Text: 200 characters.

     • Text: 30 characters.

   • Field Order (metadata fields only): Sequence in which the field is displayed on pages. Starting at 2, the number automatically increments as new fields are added. However, it is recommended to manually increment the numbers by 5, such as 15, 20, 25, and so on to accommodate fields added in the future.

   • Default Value (metadata field only): Any default value for the field.

   • Require Value (metadata field only): Prevents files from being checked in if the field does not have a value.

   • Placeholder: If selected, the field is not stored or indexed. Placeholders are often used for the parent level of a dependent list.

   • Enable on User Interface (metadata field only): If selected, the field is displayed. If deselected the field is hidden.

   • Enable for Search Interface (metadata field only): If selected, the field is indexed and thus used for searching. If deselected, the field is not indexed nor does it appear on the search pages. This will add a column x{CustomFieldName} in the DocMeta table. By default, an index is not created for that column in the DocMeta table because adding indexes are subjective on how that field is used (for example, may not be beneficial to have an index when there are only two distinct values, yes or no). An index can be created if it is desired to have an index on the metadata field.

   • Enable Option List: Enables the use of user-selectable list on a page. For more information, see Defining an Option List.

   • View Only (application field only): If selected, the field is only used in a schema view. For more information, see Using Schemas to Customize Metadata.

6. Click OK.
7. Update the database design and rebuild the search index if necessary.

7.1.3 Rebuilding the Database or the Search Index

The following table lists the events after which a database update or search index rebuild is required depending on the search engine that is used.

Note:

Rebuilding the search index is not required when using the DATABASE.METADATA search engine.

Event	Action Required
Add metadata field	Update database
Edit metadata field	Update database
Delete metadata field	Update database
Enable or disable Enable for Search Index for metadata field	Rebuild search index
Add metadata field with Enable for Search Index selected	Rebuild search index

Rebuilding the Database

If changes were made that must be saved to the database, the Update Database Design button on the Information Fields tab of the Configuration Manager page becomes active. To update the database:

1. Click Update Database Design.

2. To retain a field, deselect the box next to the field name. The field remains hidden but still exists in the database.

   You cannot remove added or edited fields using this page. They must be added then deleted later.

3. Click OK when done.

Rebuilding the Index

If changes were made that require rebuilding the search index, the Rebuild Search Index button on the Information Fields tab of the Configuration Manager page becomes active. To rebuild the search index:

1. Click Rebuild Search Index.
2. If a message asks to update the database design before rebuilding the search index, click Update Database Design to save changes to the database before proceeding.
3. When the message Rebuild initiated is displayed, click OK.

Caution:

Depending on the size of the search index and available system resources, the search index rebuild process can take several days. If rebuilding is necessary, rebuild at times of non-peak system usage.

7.2 Defining an Option List

Lists are used with custom fields to provide a selection from which users can choose a value.

Follow these steps to define a list:

1. Create the custom field and click Enable Option List, then click Configure. For more information, see Adding or Editing a Custom Field.
2. On the Configure Option List page, choose what type of list to use:

   • Multiselect List: Provides a list from which users can select multiple items.

   • Edit and Multiselect List: Provides both a text field and a data entry box. Contributors can enter values that are not in the list and they can select or enter multiple values.

   • Edit and Select List: Provides both a text field and a data entry box. Contributors can enter values that are not in the list.

   • Select List Not Validated: This option permits check in of files whose specified values are not current options. This option is valid for items checked in or updated using the Content Server Interface, the Batch Loader, and the Archiver.

   • Select List Validated: This option ensures that only files whose specified values are current options for this field are checked in. This option is valid for items checked in or updated using the Content Server Interface, the Batch Loader, and the Archiver.

   Click Advanced to display the Option List Storage page where information about the list's display and storage are specified. For more information, see Defining Option List Storage.

3. Choose how to access the values in the list:

   • Use Option List: Create a new list or edit an existing values. The name of the new list, taken from the name of the field, is inserted. For more information, see Adding or Editing Option List Content.

   • Use View: Uses values in a stored view instead of a list. Click Edit Values to change the values saved in the view. For more information, see Editing View Values.

   • Use Tree: Uses values stored in a tree rather than a view or a list. Click Edit Definition to change how the tree is viewed or stored.

4. Determine the dependencies for the list:

   • Dependent field: Check if the metadata field is subordinate to another field. This option is only available when using a view.

   • Depends on: If you select the Dependent Field, this becomes active. Enter a field name or choose the field from the list of fields.

   • Relationship: If a relationship has been defined for the view in use, select it from the list. For more information, see Schema Structure. If you select a list or view, you must specify a relationship.

5. Click OK when done.

7.2.1 Defining Option List Storage

One part of creating a list is to determine the storage options. To define storage, click Advanced next to the Option List Type on the Configure Option List page. Enter the following information:

• Storage type: Choose to either permanently store list keys or store a localized list.

• Multiselect options: Choose options to customize the appearance of a multiselect list:

  • Pad ends: Pad the length of the separator for multiselect values.

  • Storage Separator: Change the separator used to store values.

  • Display Separator: Change the separator used in the display of values.

Click OK when done.

7.2.2 Adding or Editing Option List Content

To open the Option List page, click Edit next to the Use Option List field on the Configure Option List page. Enter the following information:

• Option list values: The items to select. Each value must be on a separate line, with a carriage return between values.

• Sort order (ascending or descending): Sorts the list in alpha-numeric order. If ascending, capital letters precede lowercase letters. If descending, the reverse is done. If Ignore Case is selected, the list is sorted and the case of the letters is ignored.

• Sort Now: Sorts the list in the manner specified (ascending, and so on).

7.2.3 Editing View Values

A view displays the items available in a list. To edit a view, click Edit View next to the Use View field on the Configure Option List page. Make the following selections:

• Filter: Select a filter to alter which values are displayed on the page.

• Show Columns: Limits the number of columns to display.

• Add, Edit: Displays a page where you can add or edit new values for those currently in the view.

• Delete: Prompts to confirm the deletion of a value from the view.

• Edit Batch: Displays a page you can use to edit values in a line editor. To add values, enter the data in the appropriate columns separated by a pipe symbol (|). Each row in the table should begin on a new line.

7.2.4 Using Tree Values

A tree displays the items available in a list. If you use this method, make the following selections:

• Select relationship: Choose a relationship between options in the list.

• Remove view: Click to remove the selected view from the level in the tree.

• Selection path: Choose to display the complete path when the option is selected or to save the complete path when the option is selected.

• Separator: Specify the separator used between values.

7.3 Using Schemas to Customize Metadata

To create custom metadata fields that present a list of values, use the Information Fields tab of the Configuration Manager utility. You can also make the associated list dependent on the value of another field. This organization is called a dependent choice list (DCL).

For example, assume there are Country and State information fields. The country you select determines the choices available in the State list.

You can also use metadata schema mapping to create field lists. With metadata schema mapping, you can easily adjust option list views to accommodate localization requirements.

This section discusses the following topics:

• Schema Structure

• Creating Schemas

• Schema Example: Dynamic Lists

• Schema Example: Recursive Table for Multiple Trees

7.3.1 Schema Structure

A schema is a collection of related schema objects. The term schema also refers to a graphical depiction of the database hierarchy that is created to support the Content Server metadata schema mapping feature. The schema hierarchical structure consists of tables and their respective columns (or fields), views of the data, and the relationships between them.

Let's add City, Region, and Area Code information fields to the Country and State example to illustrate a three-tiered dependency structure.

In Figure 7-1, the sample basic schema hierarchy, one independent field has two dependent fields. Each dependent field also has a dependent field. These dependencies are also referred to as Parent/Child relationships.

Figure 7-1 Basic Schema Hierarchy Example

This three-level schema hierarchy produces five distinct metadata fields: Country, State, City, Region, and Area Code. Each field presents a specific list to the user.

The contents of the lists are contingent on whether the information field is dependent or not. Thus, the following lists result from the sample basic Country/State/Area Code schema hierarchy:

• The Country list is independent and the choices remain constant.

• The choices available in the State list are variable and depend on which country the user selects from the Country list.

• The choices available in the City list are variable and depend on which state the user selects from the State list.

• The choices available in the Region list are variable and depend on which country the user selects from the Country list.

• The choices available in the Area Code list are variable and depend on which region the user selects from the Region list

Schemas are comprised of Tablesand Relationships, as discussed in the following sections.

7.3.1.1 Tables

Schema tables are database tables that store the choices displayed in information field (metadata) lists. Tables and their columns are created using the Tables tab of the Configuration Manager. You can have multiple columns in each table but at least two are essential for producing dependent choice lists:

• The common column name used to create the dependency between one list and a second list that is dependent on the choice made from the first (for example, Country and State, respectively).

• The column that stores the choices for metadata lists.

Figure 7-2 Schema Tables Example

Using the geographical example (Country, State, City, Region, Area Code) in the three-tiered schema hierarchy, a table must be created for each branch in the schema tree structure. Additionally, the dependent tables (child tables) must contain a column that corresponds to an identical column in the table to which it is subordinate (the parent table). These corresponding columns are used to create the dependencies between the two tables and are ultimately used to generate the dependent choice lists.

For example, the tables in Figure 7-3 illustrate how the Country and State table columns might be populated. The data in each name column provides the choices available on the lists. The relationship that is created between the corresponding columns in the Country and State tables (countryID) determines what choices are displayed in the State metadata list.

Figure 7-3 Populated Schema Tables

7.3.1.2 Views

A view is a tailored presentation of the corresponding table. Views do not contain data, but they derive data from their tables. Views are used to simplify a database for use and to present data in a different perspective.

A view consists of a list of properties and associated display rules. Each table in the schema must have an associated view. Views provide information about these items:

• Specific columns in the table included in the schema. The selected columns are used to establish the dependencies between tables and also to generate the dependent choice lists.

• Internal and external column names.

• User interface display characteristics.

• Editing and sort order criteria.

7.3.1.3 Relationships

Relationships define the dependencies between tables and are essential in generating the appropriate dependent choice lists. Each defined relationship establishes the correspondence between parent and child tables. This correspondence is created by specifying the column in the child table that is dependent on the column in the parent table. Thus, the choices displayed using column data from the child table are contingent on the choice made from the corresponding column data from the parent table.

For example, in Figure 7-4, the CountryView (Country table) and the StateView (State table) use the countryID column to create a relationship that generates a parent country list and a child state list. The choices available in the State metadata list are dependent on the choice made in the Country metadata list.

Figure 7-4 Table and Column Relationships

7.3.1.4 Schema Directory Structure

Three subdirectories are associated with the Schema function, located in the /weblayout/resources directory:

• schema

• schema.work

• schema.old

The schema.work directory is usually not listed because it is a temporary directory. When the schema creation process completes, the working directory is renamed. If this directory exists it indicates one of the following:

• A large schema rebuild is in progress

• The schema is created, but there is a problem with the schema structure.

  Caution:

  If working inside the directory structure to review the Schema files and directories, be sure to close all open applications accessing these files. The directories are renamed on completion of processing. However, if external applications, such as text editors, are using these files the schema.work directory cannot be renamed.

7.3.1.5 Sample Schema-Based Lists

After the schema tables, views, and relationships are created and properly established, the lists display the appropriate choices. For example, in Figure 7-5, the Country list now displays two choices: United States and Canada.

Figure 7-5 List Example

Because the State metadata field is contingent on the Country field, the State list contains items based on the choice made in the Country list. In this case, if the United States choice is selected, the State list displays Minnesota and Wisconsin as choices. If Canada had been selected, then the State list would display Ontario and Quebec.

Figure 7-6 Dependent List Example

7.3.2 Creating Schemas

The Tables, Views, and Relations tabs in the Configuration Manager are used to create the schema structure.

• The Table tab is used to select or create the database tables.

• The Views tab is used to manipulate the views used in the schema.

• The Relations tab is used to manipulate the dependencies.

The Information Fields tab is used to create the metadata fields used on Content Server pages. The metadata fields must be correlated to the tables and views to properly display the lists.

New or modified schemas are automatically updated during each scheduled publishing cycle. Because the default interval between each publishing cycle is set to four hours, immediate results for new or modified schemas are not visible. To adjust the interval between each publishing cycle, change the default value of the associated configuration variable. For more information, see Modifying the Publishing Cycle Interval.

This section provides an overview of a simple sequence using the applicable Configuration Manager tabs to create a schema structure.

This section covers the following steps in creating a schema:

• Selecting Tables for the Schema

• Creating the Schema View

• Creating the Schema Relationships

• Adding Metadata Fields

• Enabling the Schema

• Modifying the Publishing Cycle Interval

7.3.2.1 Selecting Tables for the Schema

To select tables for the schema:

1. Use the main menu to choose Administration then Admin Applets.
2. Click Configuration Manager then the Tables tab.
3. To add tables to the schema, on the Configuration Manager: Tables tab, click Add Tables and select the tables to add to the schema from the Select Table page. When creating a new table, click Create Table.

   Important:

   You can use core system tables such as Revisions, Alias, Documents, and Users, but you cannot edit them (remove columns, alter column length, and so on.)

4. On the Create/Edit Table table_name page, select the column to be used as a primary key to establish a dependency and select Edit.
5. On the Add/Edit Column page, select the box labeled Primary Key and click OK. Select Add Recommended to add recommended columns to the table.
6. Repeat these steps for all tables to be used in the schema. When finished, click OK.

7.3.2.2 Creating the Schema View

To create the schema view:

1. Use the main menu to choose Administration then Admin Applets.
2. Click Configuration Manager then the Views tab.
3. To create a view, on the Configuration Manager: Views tab, click Add to open the Add View page: Select Table page.
4. Select the table to use in the view and click Next.
5. On the Add View page: Select Columns page, choose the columns to include in the view, and click Finish.
6. On the Add/Edit View page, select a name for the view and add information for the description. Choose the internal column (name in the database) to use in the view and choose the visible column that is displayed to end users. You can specify a display expression (text and Idoc Script) that is displayed in place of the actual field value. When done, click OK.
7. Repeat these steps for all tables to be included in the view.

7.3.2.3 Creating the Schema Relationships

To create the schema relationships:

1. After the tables and associated views are completed, click Relationships to establish the dependencies between tables and columns. A list of the currently existing schema relationships is displayed.
2. Click Add to set up a new schema relation.
3. On the Add/Edit Relationship page, enter the name of the relationship (for example, Country_State to indicate the relationship between the Country and the State tables). In the Parent Info box, select the table where the parent information resides (for example, the Country table) and the column to be used to establish the dependencies (for example, the countryID). Do the same for the Child Info field (for example, select State as the table name and countryID as the relationship).
4. Click OK when done.

   The new relationship is now displayed on the Relations list.

7.3.2.4 Adding Metadata Fields

The final phase in schema creation is to set up the metadata fields to use the columns and to configure them to use the Views and Relations created previously. For an overview of the procedure, see Adding or Editing a Custom Field and Defining an Option List.

7.3.2.5 Enabling the Schema

After you configure the schema, the views, and the relationships, click the button on the Configuration Manager page to update your database design. Click Options then Publish Schema from the Configuration Manager page menu.

Republishing (updating) of schema takes place automatically based on these things:

• Existence of the data/schema/publishlock/publish.dat file.

• The internal schedule of automatic publishing times. For information about how to modify this schedule, see Modifying the Publishing Cycle Interval.

• How long it took to publish schema last time.

Do not select Options then Publish Schema unless it is necessary to see the new Content Type quickly. The system can be overloaded when large lists are republished.

7.3.2.6 Modifying the Publishing Cycle Interval

New or modified schemas are automatically updated during the automatic schema publishing cycle. However, by default, the interval between publishing cycles is set to four hours. New schemas or changes to existing schemas are not seen in the corresponding menu lists until the completion of the next publishing cycle. Adjust the publishing cycle interval by changing the value of the SchemaPublishInterval configuration variable.

To change the interval of schema publishing cycles:

1. In a text editor, open the IntradocDir/config/config.cfg file.
2. Add the following configuration variable and value:

   SchemaPublishInterval=300
   

   The value is specified in seconds. In this configuration example, the lists are republished every 300 seconds (that is, 5 minutes).

   Note:

   Depending on the number of lists in addition to the size and complexity of each list, automatically republishing (updating) your schemas frequently can have a significant impact on your system's performance.

3. Save and close the config.cfg file.
4. Restart Content Server to apply the changes.

The queries for schema publishing are cached for up to five minutes. Publishing more frequently does not retrieve new values until the current cache expires.

If a new value is added to a metadata field, that value is not displayed on the content item's Content Information page until the next publishing cycle is complete.

If one content item is checked in with a unique value in a dynamic list and a second item is checked in with the same value but using a different case, the value is treated as one value in the list. The case used is dependent on the database sorting scheme.

For more information about creating dynamic lists, see Schema Example: Dynamic Lists.

7.3.3 Schema Example: Dynamic Lists

Creating a dynamic list enables users to add values to metadata lists. For example, if a value exists in a list, users can select the value from the list. However, if it is a new value, users can enter the value into a text field and it becomes available as an option following the next publishing cycle.

To create a dynamic list, first create a view into the table in the database. The list values are pulled directly from the metadata columns where they are stored. As content items are checked in, revised, and removed, the list values change or are updated accordingly.

The following steps illustrate an example of creating a dynamic list:

1. Use the main menu to choose Administration then Admin Applets.
2. Click Configuration Manager then the Information Field tab.
3. On the Configuration Manager: Information Field tab, click Add.
4. On the Add Metadata Field Name page, enter the name of the metadata field that has the dynamic list. For example, TestMetadata.
5. Click OK.
6. On the Add/Edit Metadata Field page, complete the fields as necessary but do not select Enable Option List.
7. Click OK.

   The page closes and the Field Info list on the Configuration Manager: Information Field tab shows the added metadata field.

8. Click Update Database Design.
9. On the Update Database Design page, click OK.
10. Open the Configuration Manager: Views tab and click Add.
11. On the Add View page: Select Table page, click Add Table.
12. On the Select Table page, select the DocMeta table.
13. Click OK.

    The Select Table page closes and the DocMeta table is added to the Tables list on the Add View page: Select Table page.

14. Click Next.
15. On the Add View page: Select Columns page, select the column to use to create the list for TestMetadata.
16. Click Finish.
17. On the Add/Edit View page, Enter a view name. For example, TestMetadata_view.
18. Click OK.
19. Open the Configuration Manager: Information Fields tab and select TestMetadata.
20. Click Edit.
21. On the Add/Edit Metadata Field page, select Enable Option List.
22. Click Configure.
23. On the Configure Option List page, select Edit and Select List from the Option List Type list.
24. Click Use View and select a view from the list. For example, TestMetadata_view.
25. Click OK.
26. On the Configure Option List page, click OK.
27. Choose Publish schema from the Options menu on the Configuration Manager: Information Field tab.

Test this list by checking in a document and entering a value into the new dynamic metadata field. Initially, the list is empty because no documents have been checked in that contain data in the TestMetadata field. However, as documents are checked in with values entered in TestMetadata, the list includes the specified values.

7.3.4 Schema Example: Recursive Table for Multiple Trees

Creating a recursive table enables the use of the data for multiple schema trees.

1. Use the main menu to choose Administration then Admin Applets.

2. Click Configuration Manager then the Information Field tab.

3. Create a database table with two columns (id, parent):

   1. Open the Tables tab and click Create table.

   2. On the Create/Edit Table table_name page, enter the table name. For example, TreeTest.

   3. In the Columns pane, click Add.

   4. On the Add/Edit Column page, enter the first column name (id) and its length. Click OK.

   5. Enter the second column name (parent) and its length. Click OK.

   6. Click OK to create the table.

4. Create a view on the table that includes both columns:

   1. Open the Views tab and click Add.

   2. In the Tables pane on the Add View page: Select Table page, select TreeTest and click Next.

   3. In the Columns pane, select the id and parent check boxes and click Finish.

   4. On the Add/Edit View page, enter the view name. For example, TreeTestView. Add display, options, and security configurations as applicable.

      Display tab: used to create rules for the relationship.

      Option tab: used to establish the sort order and criteria for the data in the schema.

      Security tab: used to define security rules for the schema.

   5. Click OK to create the view.

5. Create a relationship on the view:

   1. Open the Relations tab and click Add.

   2. On the Add/Edit Relationship page, enter the relationship name. For example, TreeTestRecursive.

   3. From the Parent Info table list, select TreeTest and in the corresponding column list, select id.

   4. From the Child Info table list, select TreeTest and in the corresponding column list, select parent.

   5. Click OK to create the relationship.

6. Open the Information Fields tab and click Add.

7. On the Add Metadata Field Name page, enter the custom metadata field's name and click OK.

8. On the Add/Edit Metadata Field page, select Enable Option List and click Configure.

9. On the Configure Option List page, click Use Tree and click Edit Definition.

10. In the Building level pane on the Edit Tree Definition page, select view for level1 list, and select TreeTestView.

    TreeTestView is entered as Level 1 in the Tree Definition pane.

11. In the Building level pane: Select relationship between the 1st and 2nd level list, click TreeTestRecursive.

    TreeTestRecursive is added under TreeTestView in the Tree Definition pane.

12. In the Building level pane: Select view for level 2 list, click TreeTestView (recursive to level 1).

    TreeTestView (recursive to level 1) is entered as Level 2 in the Tree Definition pane and the Select root button is added.

13. Click Select root.

    The Select Tree Root dialog opens.