Metadata Setup Structures Reference
All metadata setup scripts need to share a number of characteristics. First of all, they need to be compatible with a schema.
Content Manager uses card types to define a number of objects types for its core business logic. Those should not be created, updated or deleted. It is however possible to add or remove fields to or from card types, or to change LOV and LOV values for the fields.
After you have analyzed the existing fields, card types and LOVs in the database, and defined what you will change, you need to write a XML structure describing the new elements. That structure will be used by DBUT for performing the changes. Note that after using DBUT, the ASP pages that generate the user interface must still be manually updated.
- Compatible with the schema you can find here: C:\InfoShare\App\Database\InfoShareCM\XmlSetup.xsd. If it doesn't, DBUT will return errors that will have to be corrected before the change can be effective.
- The names you use for new fields, LOV or LOV values conform to the naming convention.
- Naming convention
-
When declaring customer specific metadata, you need to provide a unique identifier for the object that you declare: the element name. The element name will then be used when coding Content Manager Active Server Pages (ASPs) and in Web Services API calls.
- The following characters are allowed:
- Digits from 0 to 9
- Letters from A to Z
- A point (.)
- A hyphen (-)
- The element name should be in uppercase.
The following naming convention should be respected:Type Maximum length Naming Example List of Values (LOV) 100 characters "D" + [NAMEOFLIST] DSTATUS Values inside an LOV 100 characters "V" + [NAMEOFLIST] + [NAMEOFELEMENT] VSTATUSRELEASED Content Manager-specific field 30 characters "FISH" + [NAMEOFFIELD] FISHDESCRIPTION Customer-specific field 30 characters "F" + [NAMEOFFIELD] FVALIDATEDBY - The following characters are allowed:
- Card types
-
A card type defines the behavior of objects in Content Manager. Card types themselves cannot be created nor removed from the database, but an existing card type can be extended with customer-defined fields.
Card types Internal card type name Image - Logical CTIMG Image - Version CTIMGV Image - Language CTIMGL Library Topic - Logical CTLIB Library Topic - Version CTLIBV Library Topic - Language CTLIBL Map - Logical CTMASTER Map - Version CTMASTERV Map - Language CTMASTERL Topic - Logical CTMAP Topic - Version CTMAPV Topic - Language CTMAPL Publication - Logical CTPUBLICATION Publication - Version CTPUBLICATIONV Publication - Output CTPUBLICATIONOUTPUT Output format CTOUTPUTFORMAT Other (Word, PDF, ...) - Logical CTTEMPLATE Other (Word, PDF, ...) - Version CTTEMPLATEV Other (Word, PDF, ...) - Language CTTEMPLATEL Translation job CTTRANSJOB Configuration settings CTCONFIGURATION When you add a mandatory field to a card type, you must specify a default value.
A default value is only set when linking a field to a card type. This default value is set on all existing instances of this card type. For all newly created instances you must specify an allowed value for the field in the user interface.