Structure Browser - Administration Guide : Configuring Views

1. Views

A view defines what data to present for the objects and connections (unless a flat list of object is displayed) by defining the available and default table to apply, but also how to expand the structure (if a structure is being shown). The most common way to expand a structure is through using so called filters, which for example defines the relationship types to follow and the direction of expansion.

Figure 1. Structure Browser in action

Views used by the Structure Browser are defined either in an XML file or as a business object instances of the type "TVC View". The structure browser instance can be configured to use one or more views, which the user can choose from.

1.1. Display Mode

As of TVC release 2010.2, a new configuration parameter was added on the View called "Display Mode". With this parameter, you will be able to configure how the data should be rendered when the view is selected.

By default, a Structure Browser page is displayed as a traditional table with columns.

An alternative display mode has been added as of 2010.2 called "tiled mode", were the objects are displayed in tiled format; for further details regarding this display mode please look at this chapter.

The goal is to provide additional built-in display modes in coming releases, as well as allowing specifying custom display modes to be used.

1.2. Expand Mode

As of TVC release 2009.1, you can per view define how to expand a structure. The most common way to expand structures in TVC has been by using so called filters that define how the structure is being expanded.

Other possibilities, like expanding using a JPO or writing a custom StructureBean that implements the expand logic has also been possible. The drawback with that approach has been that you weren’t able to easily mix the expand modes used within the same Structure Browser instance.

The different expand modes to choose from will be presented in the coming chapters.

Moreover, you will be able to decide per view how the filter chooser should behave e.g. if to allow combining multiple filters, or just select a single filter, or not being able to select any filter at all.

1.2.1. Configuration

A new attribute has been added to the type: "TVC View". This attribute is called "TVC Expand Mode" and is a string attribute. Exactly what this attribute can contain is described later.

The format of the attribute is:

<mode>:[arguments]

The mode value is a case insensitive string. Some expand modes requires arguments and these are added after the mode value with a colon (':') character as separator. Possible modes are:

Mode	Arguments	Notes
filter	No	Default expand mode, e.g. expansions made with standard ENOVIA filters.
java	Required (name of Java class)	Java class defines expansion logic.
inquiry	Required (name of Inquiry)	Uses an inquiry to perform the expansion
shadow	Required (at least list of shadow types)	This is an extension to the "filter" mode, which allows defining types and/or relationships that are considered as being "shadow" (for example: Feature List objects).
jpo	Required (JPO name + method)	Uses a JPO to perform the expansion.

Mode

Arguments

Notes

filter

Default expand mode, e.g. expansions made with standard ENOVIA filters.

java

Required (name of Java class)

Java class defines expansion logic.

inquiry

Required (name of Inquiry)

Uses an inquiry to perform the expansion

shadow

Required (at least list of shadow types)

This is an extension to the "filter" mode, which allows defining types and/or relationships that are considered as being "shadow" (for example: Feature List objects).

jpo

Required (JPO name + method)

Uses a JPO to perform the expansion.

The "filter" and "shadow" modes uses standard ENOVIA filters to perform the expansion. The other modes might use filters, but aren’t required to use it. However, the standard filter-chooser can be made visible for all modes; hence the filter chooser could be used to give input to an expander even though the selected value isn’t a "real" ENOVIA filter. This is referred to as using virtual filters. In case virtual filters are used, the Role value in the View configuration should be empty.

To configure how the filter-chooser should behave, each mode can have a couple of variants. These variants are shown in the table below:

Mode	Variants	Notes
filter		Same as defining "filter-multiple"
	filter-multiple	Allows selecting multiple filters
	filter-single	Allows only one selected filter
	filter-fixed	Filter chooser is invisible
inquiry		Same as defining "inquiry-fixed"
	inquiry-multiple	Allows selecting multiple filters
	inquiry-single	Allows only one selected filter
	inquiry-fixed	Filter chooser is invisible
shadow		Same as defining "shadow-multiple"
	shadow-multiple	Allows selecting multiple filters
	shadow-single	Allows only one selected filter
	shadow-fixed	Filter chooser is invisible
jpo		Same as defining "jpo-fixed"
	jpo-multiple	Allows selecting multiple filters
	jpo-single	Allows only one selected filter
	jpo-fixed	Filter chooser is invisible
java		Java mode has no variants since the Java class defines filter mode.

Mode

Variants

Notes

filter

Same as defining "filter-multiple"

filter-multiple

Allows selecting multiple filters

filter-single

Allows only one selected filter

filter-fixed

Filter chooser is invisible

inquiry

Same as defining "inquiry-fixed"

inquiry-multiple

Allows selecting multiple filters

inquiry-single

Allows only one selected filter

inquiry-fixed

Filter chooser is invisible

shadow

Same as defining "shadow-multiple"

shadow-multiple

Allows selecting multiple filters

shadow-single

Allows only one selected filter

shadow-fixed

Filter chooser is invisible

jpo

Same as defining "jpo-fixed"

jpo-multiple

Allows selecting multiple filters

jpo-single

Allows only one selected filter

jpo-fixed

Filter chooser is invisible

java

Java mode has no variants since the Java class defines filter mode.

1.2.2. Expand Mode: Java

This expand mode requires the class name of the expander class as argument. See example below:

java:com.acme.expand.MyExpander

The class must either implement the interface com.technia.tvc.structure.Expander or extend from the base class com.technia.tvc.structure.expand.AbstractExpander. The latter is preferred. See code example below:

import com.technia.tvc.core.TVCException;
import com.technia.tvc.core.structure.Expander;
import com.technia.tvc.core.structure.ExpanderBasedStructureBean;
import com.technia.tvc.core.structure.StructureBeanNode;

public class MyExpander implements Expander {

    // Performs the expansion
    public void expandNode(ExpandCtx ctx,
                           StructureBeanNode node,
                           int levels) throws TVCException {
        ...
        StructureBeanNode child = ctx.newStructureNode(relId, objectId, true);
        node.addChild(child);
        ...
    }

    // Returns the filter mode.
    public FilterMode getFilterMode(ExpanderBasedStructureBean str) {
        return Expander.COMBINABLE;
    }

    // Returns whether or not full-expand is supported
    public boolean isFullExpandSupported(ExpanderBasedStructureBean str) {
        return true;
    }

    // Returns whether or not multi-level-expand is supported (> 1)
    public boolean isMultiLevelExpandSupported(ExpanderBasedStructureBean str) {
        return true;
    }

    // Collapses the node
    public void collapseNode(ExpandCtx ctx, StructureBeanNode node) {
        node.removeChildNodes(true);
    }
}

Use instance variables with care, as one expander instance is only created once and thus is shared between all users.

In order to support Search in Structure/Finder the expander must handle full expands properly.

1.2.3. Expand Mode: Inquiry

This expand mode requires the name of the inquiry to use. See example below:

inquiry:My Inquiry

By default, the filter selector is not shown, unless specified through the variant suffix (inquiry-single or inquiry-multiple).

If the filter chooser is enabled, the values defined in the "TVC View" instance are interpreted as virtual filters and the selected filter(s) are passed to the inquiry for later processing. See example of view definition below:

Arguments passed to the inquiry are:

Name	Description
ID	The object-id for the object being expanded.
USER	The current user
relId	If the row being expanded has a relationship-id, this is also passed.
view	The name of the current view.
filterList	The list of filters (comma separated).
rootId	The id of the root object in the structure.
parentId	The id of the object used to start the structure browser instance for.
levels	The number of levels being expanded.

Name

Description

The object-id for the object being expanded.

USER

The current user

relId

If the row being expanded has a relationship-id, this is also passed.

view

The name of the current view.

filterList

The list of filters (comma separated).

rootId

The id of the root object in the structure.

parentId

The id of the object used to start the structure browser instance for.

levels

The number of levels being expanded.

Below are some pictures showing an example inquiry.

1.2.4. Expand Mode: JPO

The JPO expand mode requires the name + method of the JPO to be used as argument. See the example below how to define this:

jpo:MyJPO:theMethodToBeCalled

This JPO should be written according to the rules as described inside this chapter .

Due to performance reasons we strongly recommend using the Java expand mode over using this mode.

1.2.5. Expand Mode: Shadow

This expand mode requires additional arguments, in order to configure the shadow types and/or relationships. The syntax for this is:

shadow:<comma separated list of types>:<comma separated list of rel-types>

The relationship type list is optional. Both the types and relationship type lists accept symbolic names.

Example:

shadow:type_FeatureList,type_RequirementList
shadow:type_AType,type_AnotherType:relationship_Rel1,relationship_Rel2
shadow:relationship_Rel1,relationship_Rel2

1.3. Configuring a View

A View configuration is preferably configured in an XML file according to the rules as described within this document .

For legacy reasons we also provide the possibility to define the view configuration as a business object within the database. This approach is however not recommended and should only be used sparsely. See this document for further details.