Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Change for an object property whether it is optional or mandatory.

Table of Contents

Introduction

Any property definition needs the specification of the required attribute. Its boolean value decides if the corresponding property is mandatory (true) or optional (false) for an object.  However, the value of the required attribute can be overwritten by a propertyReference in object type definitions or secondary object type definitions.

Tutorial Content

Handling Object Type Definitions

In an object type definition, a propertyReference can be used to set a value for the required attribute for a property. This value can be different from the value specified in the property definition. In this case, the required attribute will have the value from the object type definition.

In the example code below, the property name is defined first. The required attribute of the property name is set to true. Afterwards, the document type definition uses the property name and sets its required attribute to false by means of a propertyReference. Thus, for objects of the type document, the property name will be optional.

Overwriting of the required attribute by object type definition
<propertyStringDefinition>
    <id>name</id>
    <propertyType>string</propertyType>
    <cardinality>single</cardinality>
    <required>true</required>
</propertyStringDefinition>
 
<typeDocumentDefinition>
    <id>document</id>
    <baseId>system:document</baseId>
    <propertyReference required="false">name</propertyReference>
    <contentStreamAllowed>allowed</contentStreamAllowed>
</typeDocumentDefinition>

Handling of Secondary Object Type Definitions

An object type definition can be based on a secondary object type. Also in the definition of the secondary object type, a propertyReference can be used to set a value for the required attribute for a property. The required attribute value specified in the original property definition is again overwritten.

In the example code below, the property name is defined first. The required attribute of the property name is set to false. Afterwards, a document type definition is done without overwriting the required attribute, but based on the non-static secondary object type invoice. Finally, the secondary object type is defined. It uses the property name and sets its required attribute to true by means of a propertyReference. Thus, for objects of the type document, the property name will be mandatory.

Overwriting of the required attribute by secondary object type definition
<propertyStringDefinition>
    <id>name</id>
    <propertyType>string</propertyType>
    <cardinality>single</cardinality>
    <required>false</required>
</propertyStringDefinition>
 
<typeDocumentDefinition>
    <id>document</id>
    <baseId>system:document</baseId>
    <contentStreamAllowed>allowed</contentStreamAllowed>
    <secondaryObjectTypeId static="false">invoice</secondaryObjectTypeId>
</typeDocumentDefinition>
 
<typeSecondaryDefinition>
    <id>invoice</id>
    <baseId>system:secondary</baseId>
    <propertyReference required="true">name</propertyReference>
</typeSecondaryDefinition>

Handling of Multiple Property References

In an object type definition, it is possible to set a value for the required attribute, and additionally include multiple secondary object types specifying the required attribute as well. If at least in one definition among the others implies required=true, it will be true for every object of the corresponding type. The value true dominates over false independently on the location of the definition.

In the example code below, the property name is defined first. The required attribute of the property name is set to false. Afterwards, a document type definition is done without overwriting the required attribute of name and thus keeping the value false from the property definition. Additionally, the non-static secondary object types invoice and deliverySlip are included. The definition of deliverySlip uses the required=false from the property definition as well, since it does not overwrite it. But in the definition of invoice, it is set required=true. This value dominates over all the other definitions. Thus, for objects of the type document, the property name will be mandatory.

Overwriting of the required attribute by an object type definition and different secondary object type definitions
<propertyStringDefinition>
    <id>name</id>
    <propertyType>string</propertyType>
    <cardinality>single</cardinality>
    <required>false</required>
</propertyStringDefinition>
 
<typeDocumentDefinition>
    <id>document</id>
    <baseId>system:document</baseId>
    <contentStreamAllowed>allowed</contentStreamAllowed>
    <secondaryObjectTypeId static="false">invoice</secondaryObjectTypeId>
    <secondaryObjectTypeId static="false">deliverySlip</secondaryObjectTypeId>
</typeDocumentDefinition>
 
<typeSecondaryDefinition>
    <id>invoice</id>
    <baseId>system:secondary</baseId>
    <propertyReference required="true">name</propertyReference>
</typeSecondaryDefinition>
 
<typeSecondaryDefinition>
    <id>deliverySlip</id>
    <baseId>system:secondary</baseId>
    <propertyReference>name</propertyReference>
</typeSecondaryDefinition>

Summarizing Example

A property name is defined. It is mandatory, since the required attribute is set to true.

Property definition
<propertyStringDefinition>
    <id>name</id>
    <propertyType>string</propertyType>
    <cardinality>single</cardinality>
    <required>true</required>
</propertyStringDefinition>

An object type document is defined. The property name is included, but the required attribute is overwritten to false. Thus, the property name would be optional. But there are two secondary object types included invoice and deliverySlip, that might have specified different values for the required attribute of the property name.

Object type definition
<typeDocumentDefinition>
    <id>document</id>
    <baseId>system:document</baseId>
    <propertyReference required="false">name</propertyReference>
    <contentStreamAllowed>allowed</contentStreamAllowed>
    <secondaryObjectTypeId static="false">invoice</secondaryObjectTypeId>
    <secondaryObjectTypeId static="false">deliverySlip</secondaryObjectTypeId>
</typeDocumentDefinition>

The definition of the secondary object type invoice overwrites the required attribute of the property name to false. This value equals the specification in the document object type. In contrast, the definition of deliverySlip does not explicitly specify a value for the required attribute. This means, that the value true from the property definition will be used for deliverySlip. Since the object type document includes invoice and deliverySlip at the same time, the dominating value of the required attribute for name will be taken into account. Since true dominates over false, for the objects of type document, the property name will be mandatory.

Different secondary object type definitions
<typeSecondaryDefinition>
    <id>invoice</id>
    <baseId>system:secondary</baseId>
    <propertyReference required="false">name</propertyReference>
</typeSecondaryDefinition>
 
<typeSecondaryDefinition>
    <id>deliverySlip</id>
    <baseId>system:secondary</baseId>
    <propertyReference>name</propertyReference>
</typeSecondaryDefinition>

Summary


Read on

Managing the Schema

This tutorial shows how to use the Core API to get the tenant-specific schema of the system, how to validate a schema, and how to bring in a new schema. Keep reading

Schema - Defining Object Types

Define properties and reference them in object type definitions for the entire system, for individual tenants or for a specific app. Keep reading

DMS Endpoints

To update the instance of an object type with the property group of a floating secondary object type as well as specific values use one of the two endpoints for updating metadata. Keep reading


  • No labels