...
Page Properties |
---|
|
Status | Status |
---|
| |
---|
colour | Yellow |
---|
title | progress |
---|
|
|
---|
Priority |
|
---|
Note |
|
---|
Assignee | Antje |
---|
Resources- Antje: page created as a copy of the schema tutorial
|
Excerpt |
---|
Define Change for an object property whether it is optional or mandatory. |
...
Section |
---|
|
Column |
---|
Table of Contents Table of Contents |
---|
maxLevel | 3 |
---|
exclude | (Table of Contents|Read on|Another Tutorial|Another Concept Article|Another interesting Tutorial|Managing the Schema|Schema - Defining Object Types|DMS Endpoints) |
---|
|
|
|
Introduction
Requirements
To work through this tutorial, the following is required:
- Set-up yuuvis® API system (see minikube setup, for example)
- A user with read and write permissions on a document type in the system (see tutorial for permissions)
Example Use Case for a "Schema Flow"
The definition of the referenced properties is not explicitly mentioned in this example use case. For details please refer to "Schema - Defining Object Types, "Property Definitions"".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.
Code Block |
---|
language | yml |
---|
title | Overwriting of the required attribute by object type definition |
---|
linenumbers | true |
---|
|
<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.
Code Block |
---|
language | yml |
---|
title | Overwriting of the required attribute by secondary object type definition |
---|
linenumbers | true |
---|
|
<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.
Code Block |
---|
language | yml |
---|
title | Overwriting of the required attribute by an object type definition and different secondary object type definitions |
---|
linenumbers | true |
---|
|
<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
.
Code Block |
---|
language | yml |
---|
title | Property definition |
---|
linenumbers | true |
---|
|
<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
.
Code Block |
---|
language | yml |
---|
title | Object type definition |
---|
linenumbers | true |
---|
|
<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.
Code Block |
---|
language | yml |
---|
title | Different secondary object type definitions |
---|
linenumbers | true |
---|
|
<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
Info |
---|
|
Read on
Section |
---|
Column |
---|
| Insert excerpt |
---|
| Managing the Schema |
---|
| Managing the Schema |
---|
nopanel | true |
---|
| Keep reading
|
Column |
---|
| Insert excerpt |
---|
| Schema - Defining Object Types |
---|
| Schema - Defining Object Types |
---|
nopanel | true |
---|
| Keep reading |
Column |
---|
| 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 |
|
|
...