Home > Models

Tables, Filters and Selection Nodes

EBX.Platform supports the features of relational databases tables with a high volume of records and primary key identification.

Tables bring many benefits over aggregated lists . Beyond pure relational aspects, here are some features that tables provide:

filters and searches;
sorting, custom views and custom hierarchies;
identity constraints: primary keys, foreign keys and uniqueness constraints ;
detailed permissions for creation, modification, delete;
dynamic and contextual permissions at individual occurrence level;
detailed comparison and merge;
inheritance capacity at occurrence level (see standard inheritance );
performance and memory optimizations.

Terminology: the terms "record" and "table occurrence" are indifferently used in this documentation.

Table Definition

An element declaration with maxOccurs > 1 is declared as a table by adding the following annotation:

 <xs:annotation> 

     <xs:appinfo>

         <osd:table> 

             <primaryKeys>/pathToField1 /pathToField...n</primaryKeys> 

         </osd:table> 

     </xs:appinfo>

 </xs:annotation>

Element	Description	Required
`primaryKeys`	the primary keys of the table. Each element in the primary key is denoted by its absolute XPath notation that starts just under the table root element. If there are several elements in the primary key, the list is white-space delimited. Note: A specific whitespaces management has been defined for primary keys of type xs:string .	Yes.
`defaultLabel`	default labels to use for presenting each record inside a table or a hierarchy. Multiple variants can be specified: Default expression and localized expressions. It is specified by means of the `defaultLabel` element, for example: `<defaultLabel>Product : ${./ProductID}</defaultLabel>` `<defaultLabel xml:lang="fr-FR">Produit: ${./ProductID}</defaultLabel>` `<defaultLabel xml:lang="en-US">Product: ${./ProductID}</defaultLabel>` JavaBean that implements the interface UILabelRenderer . It is specified by means of the attribute `osd:class` ; for example: `<defaultLabel osd:class="com.wombat.MyLabel"></defaultLabel>` The last variant can be also used by hierarchies. It specifies a class that must implement the interface UILabelRendererForHierarchy . For more information about hierarchies, see also Working with Perspectives .	No.
`index`	Property used to index some fields; indexing speeds up table access for requests matching these fields. (see performances ). Notes: It is possible to define several indexes on a table. It is not allowed to define two indexes with the same name. It is not allowed to declare two indexes containing the same exact fields. An indexed field must be terminal. An indexed field cannot be a list or under a list. A field declared as an Inherited Attribute cannot be indexed. A field declared as a function cannot be indexed. For performance purposes, the following nodes are automatically indexed: Primary keys nodes (see primary keys ). Nodes defining a foreign key constraint (see foreign key constraint ). Nodes declared as being unique (see uniqueness constraint ). Auto incremented nodes (see auto incremented values ).	Non.
`mayCreateRoot`	expression that specifies when a root record may be created (see Definition modes ).	No, default is "always".
`mayCreateOverwriting`	expression that specifies when an overwriting record may be created (see Definition modes ).	No, default is "always".
`mayCreateOcculting`	expression that specifies when an occulting record may be created (see Definition modes ).	No, default is "always".
`mayDuplicate`	expression that specifies when a record may be duplicated .	No, default is "always".
`mayDelete`	expression that specifies when a record may be deleted .	No, default is "always".

The may... expressions specify when the action is possible, however the user access rights may restrict this possibility independently. The expressions have the following syntax:

expression ::= always | never | <condition>*

condition ::= [root:yes | root:no]

condition ::= [agreement:yes | agreement:no]

condition ::= [agreementAscendant:yes | agreementAscendant:no]

"always": the creation is "always" possible (but user rights may restrict this).

"never": the creation is never possible.

"root:yes": the creation is possible if the record is in a root instance.

"root:no": the creation is not possible if the record is in a root instance.

"agreement:yes": the creation is possible if the record is in a agreement instance.

"agreement:no": the creation is not possible if the record is in an agreement instance.

"agreementAscendant:yes": the creation is possible if the record is in a agreement descendant instance.

"agreementAscendant:no": the creation is not possible if the record is in a agreement descendant instance.

If the record does not verify any condition, then default is taken.

Below is an example of a product catalog as a table:

<xs:element name="product" minOccurs="0" maxOccurs="unbounded"> 

     <xs:annotation>

         <xs:documentation> 

             <osd:label>Product Table </osd:label> 

             <osd:description>List of products in Catalog </osd:description> 

         </xs:documentation> 

     </xs:annotation>

     <xs:complexType>

     <xs:annotation>

         <xs:appinfo> 

             <osd:table> 

                 <primaryKeys>/productRange /productCode</primaryKeys> 

                 <index name="indexProductCode">/productCode</index> 

             </osd:table> 

         </xs:appinfo> 

     </xs:annotation>

         <xs:sequence> 

             <xs:element name="productRange" type="xs:string"/><!-- key --> 

             <xs:element name="productCode" type="xs:string"/><!-- key --> 

             <xs:element name="productLabel" type="xs:string"/> 

             <xs:element name="productDescription" type="xs:string"/> 

             <xs:element name="productWeight" type="xs:int"/> 

         </xs:sequence> 

     </xs:complexType>

</xs:element>

Constraints on a table (primary key reference) are defined in the schema by using extended facets .

Tables have a dedicated editor in EBX.Manager:

Specifying Filters on a Table

By default, tables present all occurrences in EBX.Manager. However, the user has the ability to add filters and display only the occurrences corresponding to given criteria.

In order to do that, you must follow the steps below:

Define the filter in the schema,
Implement the class in charge of the filtering, that extends UITableFilter

As a result, a filter option will appear in the user screen, giving the opportunity to refine your search.

An implementation example can be found in the following Tutorial .

Selection Nodes

An element declaration may define a dynamic and contextual XPath selection. In this case, the Manager User Interface provides a link so that the user can navigate to the pre-filtered table that corresponds to the selection.

A selection node is useful for materializing an association between two entities , in GUI and also for validation purposes. For example, the Tutorial library schema specifies that a book is written by an author (this is made explicit by a foreign key in the 'Book' complex type definition). The opposite relation (that an author has written some books) cannot be expressed easily in XML Schema, unless we define the following selection node in the 'Author' complex type definition:

<xs:element name="linkToAuthorTitles" minOccurs="0" maxOccurs="0" type="xs:string">  

   <xs:annotation> 

      <xs:appinfo> 

         <osd:select>  

             <minOccurs>1</minOccurs> 

             <maxOccurs>10</maxOccurs> 

             <xpath>/root/Titles[au_id =${../au_id}]</xpath>  

         </osd:select>  

      </xs:appinfo> 

   </xs:annotation> 

</xs:element>

The element minOccurs specifies that, for being valid, an author must have written at least one book.

The element maxOccurs specifies that, for being valid, an author must have written at most ten books.

Note: the "official" cardinality constraints ( minOccurs="0" maxOccurs="0" ) are required because from an external XML point of view (that is, an instance of XML Schema), the corresponding node is absent. In other words, a selection node is a "virtual" element regarding XML and XML Schema.

It is also possible to specify an additional constraint on the relation. In the following example, each relation between an author and a book is valid, if the date of the publication of the book is anterior to the death of the current author:

    <osd:select>  

       <xpath>/root/Titles[au_id =${../au_id}]</xpath>  

       <constraintPredicate>date-less-than(datePub, ${../death})</constraintPredicate>  

       <constraintPredicateErrorMessage>a default error message</constraintPredicateErrorMessage>  

       <constraintPredicateErrorMessage xml:lang="fr-FR">a
french default error message

       </constraintPredicateErrorMessage>  

       <constraintPredicateErrorMessage xml:lang="en-US">a
US default error message 

       </constraintPredicateErrorMessage>  

    </osd:select>

Element	Description	Required
`xpath`	Specifies the selection to be performed, relatively to the current node. Examples: `/root/Titles[au_id =${../au_id}]` or `//Titles[au_id =${../au_id}]` or `../Titles[au_id =${../au_id}]` . The path up to the predicate (for example `../Titles` ) specifies the target table to be filtered. This part of the path is resolved relatively to the current table root. If the selection depends on the local state, the XPath expression predicate must include references to the node on which it depends, with this notation: `${ <relative-path> }` where `relative-path` is a path that locates the element relatively to the node that holds the selection link. For XPath syntax, see EBX.Manager XPath supported syntax .	Yes.
`container`	Reference of the instance that contains the target table.	No, default is current instance.
`minOccurs`	Specifies an additional validation constraint: the selection must be at least of the specified size.	No, default is 0.
`maxOccurs`	Specifies an additional validation constraint: the selection must be at most of the specified size.	No, by default the maximum is not restricted.
`constraintPredicate`	Specifies an additional validation constraint: each relation of the selection must satisfy the specified XPath predicate. The notation `${ <relative-path> }` has the same meaning as for the `xpath` element (see above).	No.
`constraintPredicateErrorMessage`	Specifies the error message to display when the constraint predicate is not satisfied. This message can be localized by means of the standard `xml:lang` attribute.	No.

Thus, by double-clicking on 'Frank Herbert' on this Author table in EBX.Manager:

And by selecting the [linkToAuthorTitles]:

One can navigate to the filtered view of the author titles:

Home > Models

Copyright © Orchestra Networks 2000-2010. All rights reserved.
Trademarks and brand names referred to in this web site relating to organizations
other than Orchestra Networks are the property of those organizations
and Orchestra Networks makes no claims to such property.