Cloud Software Group, Inc. EBX®
Documentation > Developer Guide > Data model
Navigation mode Documentation > Developer Guide > Data model

# 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`.

##### See also

- `Adaptation`

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.

##### See also

- `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.

##### Attention

- If an element is configured to be hidden in the default view of a dataset, then the access permissions associated with this field will not be evaluated.

- It is possible to display a field that is hidden in the default view of a dataset by defining a view. Only in this case will the access permissions associated with this field be evaluated to determine whether the field will be displayed or not.

- It is not possible to display a table that is hidden in the default view of a dataset (in the navigation pane).

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.

##### Note

If a group is configured as hidden in search tools or only in the text search, then all the fields nested under this group will not be displayed respectively in the search tools or only in the text search.

In all cases, the field will remain searchable in the quick search tool. A field can be excluded from all search tools, including the quick search, by defining a specific search strategy.

##### See also

- Excluding a field from search ('Void' indexing)

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.

##### Note

- If a group is configured as being hidden, then all the fields nested under this group will be considered as hidden by data services.

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`.

##### Note

- This property can only be defined on foreign key fields.

- The published view must be associated with the target table of the foreign key.

- If the published view does not exist, then the advanced selection is not available in the foreign key field.

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.

##### Note

- If a group is configured as being ignored during comparisons, then all the fields nested under this group will also be ignored.

- If a terminal field does not include the attribute `osd:comparison`, then it will be included by default during comparisons.

Restrictions:

- This property cannot be defined on non-terminal fields.

- Primary key fields cannot be ignored during comparison.

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.

##### Note

- If a group is configured as being ignored by the 'apply last modifications' service, then all fields nested under this group will also be ignored.

- If a terminal field does not include the attribute `osd:applyLastModification`, then it will be included by default in the apply last modifications service.

Restriction:

- This property cannot be defined on non-terminal fields.

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'.

Documentation > Developer Guide > Data model