OME Power User Tutorial
  1. What is a Framework?
  1. Creating a Framework File
SimpleClass MyFirstElement                            # (1)

IN OMEElementClass, OMEInstantiableClass     # (2,3)

ISA OMEElement                                             # (4)

WITH name
: "Element"                                                       # (5)

defaultname                                                      # (6)
: "An Element"

imagename                                                       # (7)
: "Graphic1.gif"

imagesize                                                         # (8)
width : 80;
height : 50

autogui : 1                                                        # (9)


Rule (1): Every class should be given a name. This name is used to refer to this class elsewhere in the framework specification.

In this example, we defined a class of an element type, whose name is MyFirstElement. Traditionally, a type class in a framework is defined as a SimpleClass.

Rule (2): All element types must be IN (an instance of) OMEElementClass.

In the example, MyFirstElement is an instance of OMEElementClass.

Rule (3): All object types that can occur in the model (i.e. can be instantiated) must be an instance of OMEInstantiableClass.

In the example, MyFirstElement is an instance of OMEInstantiableClass.

Rule (4): All element types be a specialization (a.k.a. subclass) of OMEElement.

In the example, MyFirstElement is a specialization (a.k.a. subclass) of OMEElement. OMEElementClass, OMEInstantiableClass and OMEElement are defined in OME Meta Framework (see

Rule (5): In Attribute Category: "name", OME expects one unlabeled attribute, which should be the name of the type, as experienced by the user. Any user interface dialogues that refer the type will use this value.

In the example, the name of the element type Myfirstement refers to is "Element".

Rule (6): Attribute Category: "defaultname" is optional. If an attribute category "defaultname" exists, the tool expects one unlabeled attribute, which is the default name for instances of this type (the user can always change the name of any instance). If omitted, the default name will be the name of the type, followed by the internal unique integer id assigned to the object.

In the example, the default name for the objects of type MyFirstElement is "An Element".

Rule (7): In Attribute Category: "imagename", the tool expects one unlabeled, which should be the name of a .gif file to be used to represent objects of this type. The image that is used should reside in ome/program/images/, otherwise an exception will be thrown.

In the example, the name of the image file which is used to represent an element is "Graphic1.gif".

Rule (8): Attribute Category: "imagesize" is optional. If present, OME expects two attributes labeled "width" and "height". The integer values specify the default dimensions (in pixels) of the graphical representation of objects of this type. If omitted, the default dimensions will be those of the image specified under imagename.

In the example, the width of the image used to represent an element is 80 pixels, while the height is 50 pixels.

Rule (9): Attribute Category: "autogui" is optional. If an attribute category "autogui" is presented, one unlabeled integer attribute is expected. If the value of the attribute is non-zero, the tool will automatically produce items in the graphical user interface to allow users to instantiate objects of this type. If omitted, or given a value of zero, no user interface items for this object will produced (automatically).

In the example, there will be a toolbar button created automatically in the GUI to allow users to create a new object of type MyFirstElement.

SimpleClass MyLink

IN OMELinkClass, OMEInstantiableClass                 # (10)



attribute                                                                 # (11)
to : OMEObject;
from : MyFirstElement

: "Link"

imagename                                                             # (12)
: "Arrow.gif"

width : 20;
height : 20

: "dashed"                                                              # (13)

: 1


Rule (10): Similar to elements, links must be instances of OMELinkClass and specialization of OMELink. OMELinkClass and OMELink are also defined in OME Meta Framework (see

Here, we defined a type of link named MyLink.

Rule (11): Links must have attributes labelled "to" and "from" under the attribute category "attribute". These attributes specify what kinds of objects will be valid sources and destinations for this link. This feature can be used to place constraints in your framework!

* Notice how we can use non-instantiable objects (OMEObject) in our constraints. This is a very powerful mechanism. Framework developers can create Object classes that are never meant to be instantiated but can be used to set up a hierarchy that may be utilized in establishing the proper constraints.

In this example, a MyLink can only have a MyFirstElement as its source, but any type of object (including another link) as a destination, since all instantiated objects are specialization of OMEObject (via OMEElement or OMELink).

Rule (12): Similar to an element, a link must provide an image. This image however, is used only for the "head" of the link (typically an arrow head).

Rule (13): The tool expects one unlabelled attribute under the category of "stroke". The value of the attribute must be one of the supported stroke types. If omitted, the default value for this attribute is "solid". Currently, the two supported stroke types are: "solid" - a solid line; "dashed" - a dashed line.
In the future, more stroke types can be still defined if necessary.

SimpleClass ValidChild                                         # (14)
ISA OMEElement

SimpleClass ChildA
IN OMEElementClass, OMEInstantiableClass
ISA OMEElement, ValidChild                                 # (15)
: "Child A"

: "Resource.gif"

width : 80;
height : 50

: 1


SimpleClass ChildB
IN OMEElementClass, OMEInstantiableClass
ISA OMEElement, ValidChild                             # (15)
: "Child B"

: "Task.gif"

width : 80;
height : 50

: 1


SimpleClass MyExpandableElement
IN OMEElementClass, OMEInstantiableClass
ISA OMEElement, OMEGrowableElement          # (16)
children : ValidChild                                          # (17)

: "Expandable"

: "Actor.gif"

width : 80;
height : 80

: 1


Rule (14): A user will never be able to create a direct instance of a non-instantiable class, which is not an instance of OMEInstantiableClass, but such classes can be used to express a constrain involves a certain group of classes.

In the example, a non-instantiable class named ValidChild is defined. We will make use of the this class in the following.

Rule (15): A user can bring together previously unrelated classes by declaring them as the subclasses of a same non-instantiable class.

The declarations of types ChildA and ChildB are standard element type declarations (instances of OMEElement, OMEInstantiableClass, subclass of OMEElement), but are also subclasses of ValidChild. Thus, these two class must have some common features described by ValidChild.

Rule (16): To declare an element to be expandable, we can simply make it a subclass of OMEGrowableElement.

Here we defined an expandable element named as MyExpandableElement.

Rule (17): All expandable element types should have an attribute labeled "children" under the attribute category "attribute". The value of this attribute should be some element type.

In a very loosely constrained example, we could use OMEElement. Here, we have used ValidChild to demonstrate using non-instantiable classes for constraining relationships. In this framework, ChildA and ChildB can be children (or "within the bounds") of a MyExpandableElement, but a MyFirstElement cannot.

  1. What is a Plugin?
  1. Building a Plugin
  1. What is a Plugin Method?
  1. The Lifecycle of a Plugin Method
  1. First, the View will ask the plugin method for framework information necessary to setup GUI, e.g., ask object name via getName(), ask for image file name to represent the object graphically via getImage().
  2. If a plugin method is dealing with part of a context sensitive portion of the GUI, the view may ask the method if it should be enabled via isEnabled(), while the View will present the method with a ViewContext to support the decision.
  3. When the user activates a plugin method (via the GUI), the view will ask the plugin method whether it needs any "parameters";
  4. If yes, the plugin method will respond with a Parameter object that describes the type of parameter needed.
  5. The view will then capture the corresponding parameter and transmit it to the plugin method, and then ask if more are needed.
  6. This will continue until no more parameters are required.
  7. After that, invoke() will be called, where the method "really does its job".
  8. At any point prior to invoke(), the process may be cancelled.
  9. In this event, the method needs to return to a "stable" state (i.e., forget about parameters it has received).