Customizable Searches (XML)

You can use your own complex search patterns to search for elements. To do so, make use of the inoref.xml file in the $INODIR directory; searches from this file are then available in the Find submenu.

Purpose

You can use customizable searches to store relatively complex search processes that are possible only by using several steps or not at all using the standard search so that they can be reused. The searches defined in this way can also be used when generating documentation as initial searches to determine the number of elements.

The main purpose of customizable searches is to store complex navigations in a search.

Some examples of searches that you could perform:

  • Transitive content of a package including contained references
  • All parameters contained in a classifier
  • All types used by attributes or parameters of a class

Here, a search describes the filterable navigation from one element to another in single steps.

In addition, for each navigation step you can restrict the input and output to certain stereotypes. This allows you to create extremely specific searches that are tailored to your modeling methodology.

As possible navigation steps, all so-called views are available that, for example, are listed in the Innovator API description in the class K_VW2.

Delimitation

You cannot use property filters (for example, filters for properties, stereotype properties, labels, or texts) for a navigation step as part of a customizable search.

Structure and Function of the inoref.xml File

The structure of the file inoref.xml complies with the corresponding schema file inoref.xsd. The XML file is always validated prior to an evaluation. A file will only be evaluated if it is positively validated.

The positively validated XML file is searched for a tag with the Referenz name, in which the Name attribute has the value of the Section call argument. If multiple Referenz tags with the same name exist, the one which is found first is evaluated. The content of Referenz is evaluated and converted into a call of ADClientAbleHelper.GetReferences.

Within a Referenz, at least one View tag must follow, and a ErgebnisKlasse tag can follow. They are packaged in the GetReferences view call's call parameter. The order of the view tags is important, as the server runs these views in the exact same order once it has completed its evaluation. An individual View tag is specified by its ViewName name. The following further specifications can be made for the View:

  • ViewEingabeRestriktionsKlasse restricts the evaluation of the view to the specified input objects.
  • ViewAusgabeRestriktionsKlasse restricts the evaluation of the view to the specified output objects.

Following the specification of the individual views, an ErgebnisKlasse can be specified.

ErgebnisKlasse restricts the evaluation result to the specified output objects after the processing of all of the views.

ErgebnisKlasse, ViewEingabeRestriktionsKlasse, and ViewAusgabeRestriktionsKlasse have the same structure.

PATTERN, KIND and MODE can be used as normal like in the API.

Detailed classifications can be taken from the xsd schema.

What else needs to be considered?

The customizable search processes all elements that have been found in a cycle again with all specified views. A cycle comprises the processing of all views in the specified order. This happens until the set stops growing. This means that it is rarely necessary to call transitive views.

Customizing an Existing Search Pattern

Context

The inoref.xml file contains a search for attributes present in classifiers in the Referenz tag. This is called AttributeVonClassifiern.

Only a single view is described in this search statement: OwnedElement. Together with ViewEingabeRestriktionsKlasse, this results in the following search functionality:

  • This search accepts all selected classifiers and identifies the directly contained elements. Every classifier found in the process (e.g. nested classes) is searched again for all directly contained elements.
  • When the set stops growing, the view command is finished. All elements gathered in the process (i.e. all elements directly contained by the initial classifier and all elements of classifiers directly subordinate to a classifier) are then filtered by the ErgebnisKlasse. Only attributes are accepted as ErgebnisKlasse.

The search thus delivers all attributes of classifiers that can be reached from the initial element set.

The existing search for attributes present in classifiers is to be extended to a search that finds both attributes and operations of classifiers.

How to proceed

  1. Open the inoref.xml file in the $INODIR directory and search for the Referenz tag with the name AttributeVonClassifiern.

  2. Add an additional Klassifizierung tag to the ErgebnisKlasse tag with the class name CLOperation.

  3. Execute the search.

    As well as attributes, operations are now found too.