Table of content
Back to TopBOY is not only an application but also a framework that can be extended with widgets and data sources. The framework provided implementations for all the common functionalities, such as XML file reader and writer, PV connection handling, abstract widgets, properties, OPI Runtime and OPI Editor. The framework can be extended using the extension points provided by the framework.
BOY Plugins are listed as below:
Core plugins:
org.csstudio.opibuilder: the core pluginorg.csstudio.opibuilder.rcp: the RCP fragment of
org.csstudio.opibuilder. Not needed for WebOPI.org.csstudio.opibuilder.widgets: the core
widgets pluginorg.csstudio.opibuilder.editor: the editor
plugin. Not needed for WebOPI or OPI runtime only product.org.csstudio.opibuilder.widgets.rcp: the RCP
fragment of org.csstudio.opibuilder.widgets. Not needed for WebOPI.Extra plugins:
org.csstudio.opibuilder.widgets.symbol: symbol
widgets provided by ITERorg.csstudio.opibuilder.widgets.extra: Extra
widgets provided by BNLorg.csstudio.opibuilder.examples: BOY Examplesorg.csstudio.opibuilder.imagelib: Image library
that can be used for BOY OPI.org.csstudio.opibuilder.test: test fragment for
org.csstudio.opibuilder. Not needed for building final product.org.csstudio.opibuilder.performanceTest:
Performance test resources. Not needed for building final product.org.csstudio.opibuilder.converter: EDM to BOY
converterorg.csstudio.opibuilder.adl2boy: MEDM to BOY
converter
Feature:
org.csstudio.opibuilder.feature
The extension points provided by BOY are listed as below:
org.csstudio.opibuilder.widget: Widgets can be
added to BOY using this extension pointorg.csstudio.opibuilder.graphicalFeedbackFactory:
Customized graphical feedback can be added to a specific widget using
this extension point. For example, a gauge widget should always keep
the same width and height.org.csstudio.simplepv.pvfactory: provides
different PV implementations by using this extension point. Currently
it provides utility_pv and pv_manager implementations. Both Utility
PV and PV Manager have their own extension points to allow different
data sources. Utility PV has been deprecated, but it is still useful
to switch back to it if there is a bug in PV Manager that has not
been resolved.The internal structure of BOY is described by class diagrams as below. In these diagrams, unnecessary classes or relationships have been removed so it only show the important relationships.
All BOY widgets should follow Model-View-Controller (MVC) pattern. In
BOY, the "View" is an instance of draw2D IFigure. The figure can be
totally independent with BOY. For example, some of BOY widgets' figure
such as gauge, knob and XY Graph have been contributed to Eclipse
Nebula Visualization project. The "Controller" is an instance of
AbsctractBaseEditPart
. Each widget must have a Model, EditPart and Figure class as shown in
the widgets class diagram below.
The below picture describes how data from your control system flow to the widget. PV Manager is the library that talks to your control system. Simple PV Layer is a layer that provides a simpler and abstract interface to talk to PV Manager. BOY only needs to talk the Simple PV interface.
BOY has the general PV handling code in
PVWidgetEditpartDelegate
and
ConnectionHandler
. For example, it will set the pv_value property of the widget when
PV's value changed, then the specific widget implementation will
listen on pv_value property to update the widget. The general PV
handling code also changes widget figure's border and enable state
when pv's connection, alarm or write permission states changed.
All widget properties must subclass
AbstractWidgetProperty
. Each property should define how it should be persisted to XML and
read from XML. If the property should be editable in property sheet,
it should also define its corresponding
PropertyDescriptor
. All the basic properties defined in BOY framework are shown as
below. User may define his own property type by subclassing
AbstractWidgetProperty
.
Widget Actions are the actions available on Widget's Actions property.
All Widget Actions should subclass
AbstractWidgetAction
and be created from
WidgetActionFactory
.
Scripts and Rules can be attached to every widget, so the attaching is
handled in
AbstractBaseEditPart
. It provides an
AbstractScriptStore
, so it allows to be extended to any JVM scripting languages.
Currently it provides Jython support (
JythonScriptStore
) and JavaScript support (
RhinoScriptStore
). Rules will be translated to JavaScript text and use the same
scripting mechanism to execute it.
OPI runtime can be created on any SWT composite. Currently, it
provides an Editor implementation (OPIRunner) and a View
implementation (OPIView). Most of OPI Runtime functions are
implemented in
OPIRuntimeDelegate
, so a new OPI Runtime can be easily created by using this delegate.
OPIRuntimeDelegate hooks up all OPI Runtime related features such as
context menus, toolbar, XML reading, Display navigation, macros
management etc. Some context menu actions are added using
objectContribution
extension point, so they are not shown here.
OPIEditor
hooks up all OPI Editor related features such as Actions, Context
Menus, Toolbar, Outline pages, context help etc. Some context menu
actions are added using
objectContribution
extension point, so they are not shown here.