Additional properties

Default values

In a data model, it is possible to specify a default value for a field using the attribute default. This property is used to assign a default value if no value is defined for a field.

The default value is displayed in the user input field at the creation time. That is, the default value will be displayed when creating a new record or adding a new occurrence to an aggregated list.

Example:

In this example, the element specifies a default string value.

<xs:element name="fieldWithDefaultValue" type="xs:string" default="aDefaultValue" />

Access properties

The attribute osd:access defines the access mode, that is, whether the data of a particular data model node can be read and/or written. This attribute must have one of the following values: RW, R-, CC or --.

For each XML Schema node, three types of adaptation are possible:

1. Adaptation terminal node

   This node is displayed with an associated value in TIBCO EBX®. When accessed using the method Adaptation.get(), it uses the adaptation search algorithm.

2. Adaptation non-terminal node

   This node is a complex type that is only displayed in EBX® if it has one child node that is also an adaptation terminal node. It has no value of its own. When accessed using the method Adaptation.get(), it returns null.

3. Non-adaptable node

   This node is not an adaptation terminal node and has no child adaptation terminal nodes. This node is never displayed in EBX®. When accessing using the method Adaptation.get(), it returns the node default value if one is defined, otherwise it returns null.

Access mode	Behavior
RW	Adaptation terminal node: value can be read and written in EBX®.
R-	Adaptation terminal node: value can only be read in EBX®.
CC	Cut: This is not an adaptation terminal node and none of its children are adaptation terminal nodes. This "instruction" has priority over any child node regardless of the value of their access attribute.
--	If the node is a simple type, it is not adaptable. If the node is a complex type, it is not an adaptation terminal node and does not define any child nodes. The root node of a data model must specify this access mode.
Default	If the access attribute is not defined: If the node is a computed value, it is considered to be R- If the node is a simple type and its value is not computed, it is considered to be RW If the node is an aggregated list, it is then a terminal value and is considered to be RW Otherwise, it is not an adaptation terminal node and it does not define anything about its child nodes.

Example:

In this example, the element is adaptable because it is an adaptation terminal node.

<xs:element name="proxyIpAddress" type="xs:string" osd:access="RW"/>

Information

The element osd:information allows specifying additional information. This information can then be used by the integration code, for any purpose, by calling the method SchemaNode.getInformation.

Example:

<xs:element name="misc" type="xs:string">
		<xs:annotation>
		  <xs:appinfo>
			<osd:information>
			 This is the text information of miscellaneous element.
			</osd:information>
		  </xs:appinfo>
		</xs:annotation>
</xs:element>

Default view

Hiding a field or a table in the default view

It is possible for a table or field inside a table to be hidden by default in EBX® by using the element osd:defaultView/hidden. This property is used to hide elements from the default view of a dataset without defining specific access permissions. That is, elements hidden by default will not be visible in any default forms and views, whether tabular or hierarchical, generated from the structure of the associated data model.

Example:

In this example, the element is hidden in the default view of a dataset.

<xs:element name="hiddenField" type="xs:string" minOccurs="0"/>
	  <xs:annotation>
		<xs:appinfo>
		  <osd:defaultView>
			 <hidden>true</hidden>
		  </osd:defaultView>
		</xs:appinfo>
	  </xs:annotation>
</xs:element>

Hiding groups and fields in views

It is possible for a field or a group to be hidden in all views of a table by using the element osd:defaultView/hiddenInViews. This property is used to hide elements from the tabular (including the default tabular view) and hierarchical views of a dataset without defining specific access permissions. That is, hidden elements will not be visible in any views, whether tabular or hierarchical, created from the structure of the associated data model. However, hidden elements in views will be displayed in forms.

To specify whether or not to hide an element in all views, use the osd:defaultView/hiddenInViews="true|false" element.

If this property is set to true, then the element will not be selectable when creating a custom view. As a consequence, the element will not be displayed in all views of a table in a dataset.

If a group is configured as hidden in views, then all the fields nested under this group will not be displayed respectively in the views of the table.

Hiding a field in structured search tools

To specify whether or not to hide an element in structured search tools, use the element osd:defaultView/hiddenInSearch="true|false|textSearchOnly".

If this property is set to true, then the field will not be selectable in the text and typed search tools of a dataset.

If this property is set to textSearchOnly, then the field will not be selectable only in the text search of a dataset but will be selectable in the typed search.

Example:

<xs:element name="hiddenFieldInSearch" type="xs:string" minOccurs="0"/>
	  <xs:annotation>
		<xs:appinfo>
		  <osd:defaultView>
			 <hiddenInSearch>true</hiddenInSearch>
		  </osd:defaultView>
		</xs:appinfo>
	  </xs:annotation>
</xs:element>

In this example, the element is hidden in the text and typed search tools of a dataset.

<xs:element name="hiddenFieldOnlyInTextSearch" type="xs:string" minOccurs="0"/>
	  <xs:annotation>
		<xs:appinfo>
		  <osd:defaultView>
			 <hiddenInSearch>textSearchOnly</hiddenInSearch>
		  </osd:defaultView>
		</xs:appinfo>
	  </xs:annotation>
</xs:element>

In this example, the element is hidden only in the text search tool of a dataset.

Hiding a field in Data Services

To specify whether or not to hide an element in data services, use the element osd:defaultView/hiddenInDataServices. For more information, see Disabling fields from data model.

Example:

<xs:element name="hiddenFieldInDataService" type="xs:string" minOccurs="0"/>
	  <xs:annotation>
		<xs:appinfo>
		  <osd:defaultView>
			 <hiddenInDataServices>true</hiddenInDataServices>
		  </osd:defaultView>
		</xs:appinfo>
	  </xs:annotation>
</xs:element>

In this example, the element is hidden in the Data Service select operation.

Defining a view for the combo box selector of a foreign key

It is possible to specify a published view that will be used to display the target table or the hierarchical view of a foreign key for a smoother selection. If a view has been defined, the selector will be displayed in the user interface in the combo box of this foreign key. The definition of a view can be done by using the XML Schema element osd:defaultView/widget/viewForAdvancedSelection.

Example:

In this example, the name of a published view is defined to display the target table of a foreign key in the advanced selection.

<xs:element name="catalog_ref" type="xs:string" minOccurs="0"/>
	  <xs:annotation>
		<xs:appinfo>
			<osd:otherFacets>
				<osd:tableRef>
					<tablePath>/root/Catalogs</tablePath>
				</osd:tableRef>
		  	</osd:otherFacets>
		  <osd:defaultView>
			 <widget>
			 	<viewForAdvancedSelection>catalogView</viewForAdvancedSelection>
			 </widget>
		  </osd:defaultView>
		</xs:appinfo>
	  </xs:annotation>
</xs:element>

See Combo-box selector for more information.

Customizing a default widget

A widget can be defined using the data model assistant. See Default view > Widget for more information.

Customizing REST data services

Default view configuration is managed in REST data services through the session channel.

Comparison mode

The attribute osd:comparison can be included on a terminal node element in order to set its comparison mode. This mode controls how differences are detected for the element during comparisons. The possible values for the attribute are:

default

Element is visible during comparisons of its data.

ignored

No changes will be detected when comparing two versions of the content in records or datasets. During a merge, the data values of an ignored element are not merged when contents are updated, even if the values are different. For new content, the values of ignored elements are merged. During an archive import, values of ignored elements are not imported when contents are updated. For new content, the values of ignored elements are imported.

Example:

In this example, the first element is explicitly ignored during comparison, the second element is explicitly included.

<xs:element name="fieldExplicitlyIgnoredInComparison"
	type="xs:string" minOccurs="0" osd:comparison="ignored"/>
<xs:element name="fieldExplicitlyNotIgnoredInComparison"
	type="xs:string" minOccurs="0" osd:comparison="default"/>

Apply last modifications policy

The attribute osd:applyLastModification can be defined on a terminal node element in order to specify if this element must be included or not in the 'apply last modifications' service that can be executed in a table of a dataset.

The possible values for the attribute are:

default	Last modifications can be applied to this element.
ignored	This element is ignored from the apply last modifications service. That is, the last modification that has been performed on this element cannot be applied to other records.

Example:

In this example, the first element is explicitly ignored in the 'apply last modifications' service, the second element is explicitly included.

<xs:element name="fieldExplicitlyIgnoredInApplyLastModification"
	type="xs:string" minOccurs="0" osd:applyLastModification="ignored"/>
<xs:element name="fieldExplicitlyNotIgnoredApplyLastModification"
	type="xs:string" minOccurs="0" osd:applyLastModification="default"/>

Categories

Categories can be used for "filtering", by restricting the display of data model elements.

To create a category, add the attribute osd:category to a table node in the data model XSD.

Filters on data

In the example below, the attribute osd:category is added to the node in order to create a category named mycategory.

<xs:element name="rebate" osd:category="mycategory">
	  <xs:complexType>
		<xs:sequence>
		  <xs:element name="label" type="xs:string"/>
		  <xs:element name="beginDate" type="xs:date"/>
		  <xs:element name="endDate" type="xs:date"/>
		  <xs:element name="rate" type="xs:decimal"/>
		</xs:sequence>
	  </xs:complexType>
</xs:element>

To activate a defined category filter on a dataset in the user interface, select Actions > Categories > <category name> from the navigation pane.

Predefined categories

Two categories with localized labels are predefined:

• Hidden

  An instance node, including a table node itself, is hidden in the default view, but can be revealed by selecting Actions > Categories > [hidden nodes] from the navigation pane.

  A table record node is always hidden.

• Constraint (deprecated)

Restriction

Categories do not apply to table record nodes, except the category 'Hidden'.