Table of Contents
This document describes the use of the Open Mashups Studio (thereafter OMS) Firefox extension. The reader will find all what's needed to understand the mashups model used, and how this model is exposed in the OMS.
The first part focuses on the Open Mashups model, describing the component model and the execution semantics, while the second part details the configuration and usage of the OMS.
Open Mashups Modeling (OMM) is a domain specific language dedicated to applications based on component assembly. It uses a data flow paradigm to connect components and a very simple type system to represent exchanged data. Creating applications in OMM only requires a few concepts to be understood, namely :
-
What makes an application ?
-
What is a component ?
-
Which kind of data is produced and consumed by a component ?
-
Execution semantics.
An OMM application is composed of a set of meta-data and of a number a dialogs.
The meta-data items are used to convey information about the application and its author. Editing meta-data is available in the Studio from the menu entry.
| Field | Description |
|---|---|
| Short name | A short name used to identify the application. Does not need to be unique. |
| Description | A short text describing the purpose of the application. |
| ID | A unique identifier attached to this application. It can be generated by a UUID generator, or from a domain name you own (e.g. myapp@mydomain.com). |
| Version | The application version. |
| Author | The author of the applicaiton, identified by its name, email and URL. |
| Main dialog | The name of the main dialog for this application. This dialog will be opened when launching the application. |
Table 1. Application meta-data
Each dialog in an OMM application is identified by its name, and is composed by two main parts : the user interface definition, and the behavior definition.
The user interface definition is made of graphical components that can be organized hierachically. Some are simple components, like button, label, texfield while some are more sophisticated components such as a photo album, a map, a grid...
The behavior definition describes how components are connected together : which data they consume and which data they produce. All the data are manipulated as variables that are global to the application. This means that you can share data between dialogs very easily. One important thing to note is that the behavior part will include graphical components as well as non-graphical components : there is no difference between these two kinds of components as far as the behavior is concerned.
We've seen that components are the cornerstone of OMM. A component can be statefull or stateless, and exposes one or several actions. Each action takes a variable as input and produces either an output or an error variable. Components can also emit events, which are a special kind of output, and also produce a variable.
Graphical components are always statefull, but black box components may be either stateless or statefull. Events are used by both kinds of components. For instance, the timer component is a statefull black box component that emit events.
Components are grouped into component libraries to ease their management.
To allow non programmers to easily create applications, we decided to restrict the data produced and consumed by components to a single type: the Table type. The Table type is analogous to a spreadsheet: it's a list of rows, each row being composed of a number of named columns. To be able to combine different component together, we provide a mapping language based on the OMG standard called OCL (Object Constraint Language) [OCL] to build a new Table from the data of other tables. In an application, each event and action produces a Table, which is a variable. Variable can have initialization value, and be made persistent across several execution of an application.
Actions are executed when the variables it needs to build its input have been modified: this is an execution model based on variables update dependency. We represent it graphically by data flows that join at the input of a method. A special case is made when we want to be able to call a method if only a given input variable has changed, by labelling this input as a trigger : such inputs will appear as orange connectors in the studio.
The Open Mashups Studio is a Firefox extension, available either from the Mozilla add-ons site, or from the Open Mashups web site. Once installed, it is accessible from the menu entry.
When using the OMS for the first time, you need to fill in a few configuration parameters. The dialog is available from the menu entry, and has several sections :
General
General preferences allows you to control two features :
-
Choosing if you want to run applications in their own window or in a browser tab.
-
Allow Open Mashups to automatically bookmark links ending in ".omp". Such links will be bookmarked and tagged with the "open-mashups" tag.
User
User preferences are used to gather your name, email address and repository password. They are used to populate application meta-data with meaningful default values as well as for authenticating the user on application repositories.
Repository
Repositories are online services that allow users to share their applications. By default, the OMS is configured to use the Open Mashups repository.
You can also specify a WebDAV URI. Some service providers offer free WebDAV accounts and storage, like mydisk.se.
Libraries
Librairies are used to specifiy which components will be available in the OMS, both at design time and at run time. A library provider must create a catalog file that contains the location of various files needed by the OMS.
You can add, remove and reorder the catalogs (this allows to override components definitions).
The OMS itself comes with a catalog for the standard libraries and a few optionnal ones. This catalog can't be removed.
Themes
The OMS runtime supports two rendering modes : the "Basic theme", and a dark theme with animation effects. You can switch between themes without any application-specific modifications.
The OMS user interface is organized in several Views that give access to different functionnalities to create your applications :
-
The Project view allows you to manage the application's dialogs and additionnal resources.
-
The Interface view allows you to create the user interface of the application.
-
The Behavior view allows you to specify how components are connected.
-
The Source view show a XML representation of the application.
Views can be opened, folded or closed. To open or close a view, use the menu. To fold and unfold a view, click on its title. The following screenshot shows the OMS with the Project View folded, the Interface view opened and the Behavior and Source views closed :
The OMS provides help (either by pressing F1 or from the menu) in a contextual manner. This means that is you keep the help window opened, its content will change depending on what you are doing. The help window also provides two direct shortcuts, one to access the help starting point :
and the other to access the components documentation :
To create a new application, use the menu entry. This will create an empty application and open the settings dialogs for the new application :
The meaning of the fields is explained in Section 2.1, “OMM applications”.
Once you have close this dialog (it is available at any time from the menu item) you can start designing your application. In the following sections we'll describe how to use each of the views.
The interface view is composed of two main areas : on the left side, the component palette, and the design area on the right. To add a new widget, simply drag and drop it from the palette to the design area.
Widgets are grouped in three categories in the panel :
-
Positioning widgets : this includes two container widgets (vertical box and horizontal box) and a splitter.
-
Inputs : these widgets are mainly used to gather user input.
-
Display : these widgets are mainly use to display data.
The hovered widget is shown with a green border and a white background, while the selected widget has a red border and a white background.
You can also reorganize already placed widgets by drag and droping them to a new position.
A contextual menu is accessible and gives acess to two functionnalities : editing the widget parameters and removing the widget.
Accessible either through the contextual menu or by double clicking the selected widget, a dialog is used to edit widget properties. At first it opens showing only the properties that are specific to the widget being edited :
Here we are editing a textfield, and are allowed to specify a default text, the kind of textfield (normal, email, password), if it is a multiline textfield and how many lines to display.
By clicking on the "+" sign on the top right of the dialog, you can access additionnal properties that are common to all widgets :
The meaning of these additionnal parameters is as follows :
-
name : A name for this component. Mandatory if you want to use the component in the behavior view.
-
class : A free text field used for styling purposes.
-
pack : The pack attribute specifies where child elements of the box are placed when the box is larger that the size of the children. For boxes with horizontal orientation, it is used to indicate the position of children horizontally. For boxes with vertical orientation, it is used to indicate the position of children vertically. The align attribute is used to specify the position in the opposite direction. The following values are valid :
-
start : Child elements are placed starting from the left or top edge of the box. If the box is larger than the total size of the children, the extra space is placed on the right or bottom side.
-
center : Extra space is split equally along each side of the child elements, resulting the children being placed in the center of the box.
-
end : Child elements are placed on the right or bottom edge of the box. If the box is larger than the total size of the children, the extra space is placed on the left or top side.
-
-
align : The align attribute specifies how child elements of the box are aligned, when the size of the box is larger than the total size of the children. For boxes that have horizontal orientation, it specifies how its children will be aligned vertically. For boxes that have vertical orientation, it is used to specify how its children are algined horizontally. The pack attribute is related to the alignment but is used to specify the position in the opposite direction. The following values are valid :
-
start : Child elements are aligned starting from the left or top edge of the box. If the box is larger than the total size of the children, the extra space is placed on the right or bottom side.
-
center : Extra space is split equally along each side of the child elements, resulting the children being placed in the center of the box.
-
end : Child elements are placed on the right or bottom edge of the box. If the box is larger than the total size of the children, the extra space is placed on the left or top side.
-
baseline : This value applies to horizontally oriented boxes only. It causes the child elements to be aligned so that their text labels are lined up.
-
stretch : The child elements are stretched to fit the size of the box. For a horizontal box, the children are stretched to be the height of the box. For a vertical box, the children are stretched to be the width of the box. If the size of the box changes, the children stretch to fit. Use the flex attribute to create elements that stretch in the opposite direction.
-
-
flex : This attribute indicates the flexibility of the element, which indicates how an element's container distributes remaining empty space among its children. Flexible elements grow and shrink to fit their given space. Elements with larger flex values will be made larger than elements with lower flex values, at the ratio determined by the two elements. The actual value is not relevant unless there are other flexible elements within the same container. Once the default sizes of elements in a box are calculated, the remaining space in the box is divided among the flexible elements, according to their flex ratios.
The behavior view is also organized with a left pane showing the component, and a design area.
Since the component list can grow big depending on how many additionnal catalogs you have, a search box is available to filter components :
In the behavior view, the contextual menu will be different depending on wich element is hovered by the pointer :
-
When in an empty place, the contextual menu offers the possibility to add a new variable.
-
When on a component, you can add an action and eventually remove or hide the component.
-
When on an action, you can edit it or delete it.
-
When on a connector, you can delete it, mark it as a trigger and as persistent.
-
When on a variable, you can edit it or delete it.
To add a component from the behavior panel, simply drag and drop it to the design area : you'll end up with an empty white component. Note that if this is a stateful component, you'll have to specify a name for it, and that adding twice a stateless component is a void operation.
To include a widget in the behavior, drag and drop it from the interface view to the behavior design area. Here again, you'll need to name the widget if it was unnamed. Widget components appear in orange to be distinguishable from black box components. Moreover, when the pointer hovers on a widget in the behavior pane, the corresponding widget is highlighted in the interface view with a green rounded border (the interface view may scroll to show the selected widget).
Stateful components can have parameters. They are edited in a dialog similar to the one in Section 3.5.1, “Editing widget parameters”. The only difference is that black box components have no common set of parameters.
Each component provides a number of actions. To use an action, select it from the submenu in the contextual menu. Action are shown as a light blue region inside the component. The description of the action appears in red if the action is not configured.
The contextual menu allows you to remove an action. If it was connected to other components, all the relevant connections are also deleted.
In an empty place of the design area, the contextual menu only choice is to create a new variable. This will open this dialog :
You will need to provide at least a name for the variable, and optionnaly initialize a number of fields with values.
Once you have completed this dialog, the new variable appears as a yellow circle, whit its name appearing when the mouse hovers it :
You may have noticed that components, actions and variables have small colored circles at various positions. These circles are connection points, with the colors denoting the kind of connection :
-
blue : input and outputs (used for actions and variables).
-
red : error output for actions.
-
green : events.
To create a connection between two connection points, simply hold down the mous button in the first circle, and drag it to the second one. The line color will reflect the possibility to create the link (yes if green, no if red).
The possibilities for creating connections are as follows :
-
Events can only be connected to action inputs :
When a component can emit several events, a dialog allows to choose the one to be connected :
-
Action inputs can be connected to three kind of outputs :
-
Action outputs and errors can only be connected to an action input :
Once a connection is made, it will appear either as a purple line for output/input and errors/input connectors or as a green one with the event name for events.
The contextual menu for connectors has several entries : one for removing the connector, one to label the connector as a trigger (such connectors are colored in orange) and one to mark them as persistent.
A persistent output will be reminded between application runs.
Once you have connected your components, it's time to configure the action parameters to map the action inputs to the outputs it depends on. This is done in a dedicated dialog accessible either by double clicking on the action or from its contextual menu.
If the action was not configured at all, the OMS will try to find the best matching associations for the inputs, as shown in the screenshot above.
Each mapping can be either a field Map, a value assignment or a variable copy. Note that order matters.
The project view is used to manage applications dialogs and the resources that will be embedded into the application.
When in the dialog section, you can add a new dialog using the button. You have to give a name to the dialog - this allows it to be selected as the main dialog in the settings dialog (cf. Section 3.4, “Creating a new application”).
It is also possible to delete a dialog (using the button) if your application has more than one dialog.
Resources are all files that are needed for the application and
that you want to embed to avoid access to remote resources. They can
be any kind of file, and will be accessible using a special URI scheme
: for instance, the twitter_logo.png resource file is accessible with
the ompres://twitter_logo.png URI.
Double clicking on a resource will open an integrated editor if it is a text file, an HTML file or a PNG image. Other kind of resources will have to be edited by an external editor.
Platform specific styles offer the possibility for the application designer to customize the look and feel of its application. This is done by CSS stylesheet, using the widget names as identifiers and the class attribute.
The Firefox runtime will look for a file named
xul.css to contain platform specific
styles.
Running an application is available either through the F11 key, or from the File>Run menu entry. The main dialog of the application will be opened.
Two theme engines are available in the OMS : the basic engine, and the dark engine. You can choose your favorite one in the preference dialog (cf. Section 3.1, “Themes”).
Here is a screenshot of the GeoFlikr sample using the basic theme : a contextual menu is available that allows to take screenshots of the application, to switch to full-screen view and to activate or desactivate the activity indicator showing long running actions.
And the same one using the dark theme :
The dark theme engine also provide an iconize function : this shows the application running in small vignette that you can move anywhere on your desktop. Clicking on the vignette renders the window its initial size.
To get a better idea of what's going on when an application is running, you can open the debug console using the menu entry. The console lists the running application, and for each one you can :
