OPI Validation tool built on the Eclipse's validation framework provides means to validate and quickly fix existing OPI files with regards to the OPI schema. Validation can be invoked manually on an OPI file or group of OPI files by invoking the "Validate" context menu item. Manually invoking validation will run validation in the background. When validation completes, a validation results dialog is displayed, and any problems found will be shown in the Problems view. To open the Problems view, select Problems from the menu bar Window -> Show View -> Other... -> General -> Problems. Double-clicking on an error/warning/info message in this view opens the respective editor (OPI Editor or OPI Runtime) and highlights the failing widget. Finally, from the Problems view, fixes can be applied on one or many error/warning messages by invoking the "Quick fix" context menu item. A confirmation is asked for making a backup before applying the fix. After the quick fix is completed, the modified OPI files are revalidated.
The validation plugin requires two input files OPI Schema and Validation Rules definition file. First make sure that you have a schema file well defined and that the properties of individual widgets in the schema are exactly like you want them. Then you need to compose the validation rules; for each property of a widget there can be exactly one defining how that property is validated - read-only: the user is not allowed to change this property; write: the user has to specify this property; read/write: the user can overwrite the default property value. After you have the definition file ready, select it in the OPI Validation preferences page.
Validation rules definition file is a regular properties file with a .def extension. You should define every rule in a single line and use '#' or '!' for line comments. There are three general rules definitions that each property can have:
The rules should be defined for all properties of all widgets that should be validated. If the property is not listed here it is automatically assumed to be readable/writable. Each property can be either defined for all widget that have it, or for a specific widget. The widget specific definition will always have precedence over the general rule definition.
Rules should be defined as property=rule pairs, where property is the name of the widget property (as it appears in the xml) and rule is one of the three options listed above. If you want to define a general rule (valid for all widgets), you should use only the property name. If you want to define a widget specific rule, you should prefix the property with the widget type and a dot. For example, if you wish to set the border color of all widgets to RO, you can write border_color=RO. If you wish to set it to RO only for the action button, you can write actionbutton.border_color=RO. Note that you can either use a full widget name (e.g. org.csstudio.opibuilder.widgets.ActionButton), or just the simple name. The rules are case insensitive. The property can also be defined as a regular expression; in this case any property that matches the regular expression will follow that rule (if there is no more specific rule for that property).
Examples:
Fonts and colors specified by the user are checked against the BOY font and color definition files.
Rules can also specify additional acceptable values. These are the values that may or may be not identical to whatever is used in the OPI schema, but they are acceptable to be used for the specified property. For example: the OPI schema defined that the background color of a groupingContainer should be 'IO Background', however the value 'IO Area Background' is also acceptable. Acceptable values should be placed in rectangular brackets and separated by a semi-colon.
groupingContainer.background_color=RO [IO Background; IO Area Background]
Complex properties like rules, actions, and scripts can also have a rule, which states that certain sub property has to be removed if it is present. To apply such rule, append the name of that sub property to the rule definition in curly braces. For example: we want to remove all rules named BorderRule and NoBorder
rules=RW {BorderRule; NoBorder}
Each validation failure is assigned one of the three possible severities: error, warning or info. Any RO rule violation is considered to be an error, unless it is a font or color property and the value that is used is one of the predefined values. WRITE violations have info severity, unless it is a font or color property and the value that was used is not one of the predefined values.
The Preferences page is available in CSS Applications, Display, BOY, OPI Validation.
The following options are available: