If multiple filter retrievers are specified via XMCoreClasses/Retrievers, this property contains the name of the filter variant in the technical model.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Describes the default sort order of an attribute in a many

0 means None

1 means Ascending

2 means Descending

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Describes the default sort order position of an attribute in a many

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Code, that retrieves a vector of all instances of the core class.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Code, that counts all instances of the core class.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, the respective Retriever has an additional attribute of type integer which determines the maximum number of returned instances.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, the respective Retriever has an additional attribute of type String which allows to define text expression based queries which implicitly define other filter settings.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, the feature is sortable. If so, the user can choose a sort order which influences the order of the query result.

If specified on an attribute, this specification is used, otherwise a possible default setting on the type of the attribute is used. If specified on a class, this specification is provided as such a default value.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Like XMLogicRertiever/Sortable specified on an attribute, but in contrast not superior, but inferior to the specification of the associated type.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, the feature is filterable. If so, the user can enter or select filter expressions which constrain the query result.

If specified on an attribute, this specification is used, otherwise a possible default setting on the type of the attribute is used. If specified on a class, this specification is provided as such a default value.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Like XMLogicRertiever/Filterable specified on an attribute, but in contrast not superior, but inferior to the specification of the associated type.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, this feature determines the sort order of an associated attribute.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, this feature is a filter for some attribute of the target instances.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If provided, this code is used to get the respective attribute value of a retrieved instance. Used in InMemory filter.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If provided, this type is used instead of the attribute core type in comparisons to determine the sort order. If provided, usually an AttributeAccessor has to be specified as well.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, this feature is a retriever filter containing filter and sort order attributes in turn.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, this feature is a retriever filter containing filter and sort order attributes in turn, corresponding to derived instances.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, this feature is a special attribute determining the maximum amount of instances to be returned.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, this feature is a special attribute which allows entry of text expression queries.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

The type of filter that is used to select objects based on the associated attribute.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Type for retrieving appropriate Selector from retriever

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

Code, that creates an instance of property 'FilterType'.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

A list of named code expressions that are used as fixed filter values in the retriever filter of the respective name. If such an expression is defined for an attribute of a filter retriever, it's value is used and at the same time the filter attribute is not shown anymore in the user interface, and it is made readonly in the BL.

Normally, this property is applied on attribute level. If it is applied on class level, it refers to the implementation class filter parameter.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

A list of named code expressions that can be loaded by the given filter configuration name as filter values into a retriever filter of the given filter name.

Such named filter configuration can be used to conveniently create preconfigured filter retriever.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

Code, that creates an instance of property 'FilterType' based on filter arguments.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Arguments used by an FilterInitialiserWithArguments.

Applies to

▸ Model level: ☑ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Code, that creates an instance of class GenericFilterBuilder, which can be used to generically manipulate this filter member.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

If true, this feature is not a filter itself, but a filter retriever, which in turn contains filter attributes.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If this feature is a FilterContainer, this property specifies an optional name of a retriever filter, which is used in the filter container instead of the default retriever filter.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Code, that creates an instance of property 'FilterContainer'.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☑ association ends ∙ ☐ states

A list of sub classes, whose filters are included in this filter. This allows for searching in fields of derived classes.

Only filters for members of that exact sub class are included, thus, if there are intermediate classes in the derivation chain, all of them have to be listed explicitly if desired.

Additionally, for each sub class the name of a filter can be specified, if no name is given the default filter is used.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, the respective retriever for some class C is not derived from corresponding retrievers of bases of class C, which is normally the case.

The purpose of such non derived retrievers is to use them in base class retrievers as sub class filters, see XMLogicRetriever/FiltersFromSubClasses. In this situation, the base class members are already represented in the base class filter, so they need to be omitted in the included sub class filter.

This property belongs to the technical model. Is is automatically set if the retriever filter name is "DirectMembersOnly".

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

Marker for renderer. If true, renderer can initiate an inital load on filter.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If true, the data browser load initial data from filter.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

A list of expressions, creating a JavaClass

RetrieverFilter

each. These filters are passed to all query builders, so that the respective filtering takes places in conjunction with all queries for this class.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If provided, these codes are used to actually retrieve instances in the RetrieverFilter classes. If there is no matching code provided for a filter, the respective retrieval function is automatically implemented in backend specific classes.

Matching codes are specified by name, i.e., the name of the code snippet at this property must match the name of the corresponding retriever filter class id. E.g., if the retriever filter class id is 'Filter/XYZ', the corresponding name here is 'XYZ'.

Note: usually, a matching XMLogicRetriever/NamedFilterCountBodies entry should be provided at the same time. If only a 'NamedFilterRetrieveBodies' entry is provided, it is used, and the count operation is implemented based on that retriever by just counting the result instances. This may be a performance issue, so usually both properties shall be provided as a pair.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If provided, these codes are used to actually count instances in the RetrieverFilter classes. If there is no matching code provided for a filter, the respective retrieval function is automatically implemented in backend specific classes.

Matching codes are specified by name, i.e., the name of the code snippet at this property must match the name of the corresponding retriever filter class id. E.g., if the retriever filter class id is 'Filter/XYZ', the corresponding name here is 'XYZ'.

Note: an entry here is only used if at the same time a matching XMLogicRetriever/NamedFilterRetrieveBodies entry is provided. A 'NamedFilterCountBodies' entryalone is not used. In contrast, if only a 'NamedFilterRetrieveBodies' entry is provided, it is used, and the count operation is implemented based on that retriever by just counting the result instances. This may be a performance issue, so usually both properties shall be provided as a pair.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If provided, this code is used to actually retrieve instances in the RetrieverFilter classes. If this code is not provided, the retrieval function is automatically implemented in backend specific classes.

The code snippet here is provided in the technical model and is obtained from XMLogicRetriever/NamedFilterRetrieveBodies by selecting the appropriate entry by retriever filter class id.

Note: usually, a XMLogicRetriever/FilterCountBody should be provided at the same time. If only a 'FilterRetrieveBody' is provided, it is used, and the count operation is implemented based on that retriever by just counting the result instances. This may be a performance issue, so usually both properties shall be provided as a pair.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

If provided, this code is used to actually count instances in the RetrieverFilter classes. If this code is not provided, the retrieval function is automatically implemented in backend specific classes.

The code snippet here is provided in the technical model and is obtained from XMLogicRetriever/NamedFilterCountBodies by selecting the appropriate entry by retriever filter class id.

Note: this property is only used if at the same time a XMLogicRetriever/FilterRetrieveBody is provided. A 'FilterCountBody' alone is not used. In contrast, if only a 'FilterRetrieveBody' is provided, it is used, and the count operation is implemented based on that retriever by just counting the result instances. This may be a performance issue, so usually both properties shall be provided as a pair.

Applies to

▸ Model level: ☐ logical model ∙ ☑ technical model

▸ Model elements: ☐ packages ∙ ☑ classes ∙ ☐ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states

A dot separated path of attributes, originating at the current class, used to access a related remotely associated attribute for filtering purposes. Typically used with attributes of stereotype Stereotype

FilterOnly

.

Applies to

▸ Model level: ☑ logical model ∙ ☐ technical model

▸ Model elements: ☐ packages ∙ ☐ classes ∙ ☑ attributes ∙ ☐ operations ∙ ☐ association ends ∙ ☐ states