Other Mechanisms

There are many components to form the whole toolkit architecture; following is some remarkable designs in the toolkit which make the toolkit more flexible, friendly, and easy-to-use.

4.4.1 Extensible Widgets

Figure 4-3: The widget architecture with regard to the JavaBeans.

Since the version of PUML specification changes over time, the design of a widget which represents a PUML tag element must be extensible to increase the software usability. For this reason, JavaBeans component framework described in the second chapter is conducted into the widget design, each widget is regarded as a pluggable component in the toolkit and the composition of an extensible widget is

illustrated in Figure 4-3.

Widget User-Interface

The widget user-interface is a component which is responsible for drawing a customized outlook; however, this component is not essential since we provide a default user-interface component for those widgets without any user-interface components. While adding a widget to the design canvas, the widget user-interface component will be wrapped inside a wrapper component. The wrapper component not only provides a unify interface to access the widget it contains but also draws a dotted border while the widget is selected, developers can then visually identify the selected widget in this manner.

Widget Bean

The widget bean follows the JavaBeans design principle to store data inside and expose access methods outside through the widget bean description. In the toolkit, a widget bean’s field contains not only all of the attributes of its corresponding PUML tag element but also other values which provide necessary information about drawing the widget user-interface.

Nevertheless, for the purpose of mapping a widget to the corresponding PUML tag element, the widget bean is therefore required to implement a common interface which is listed at Appendix A. The common interface provides five essential information to the program inside, the first is the qualified name of the corresponding PUML tag element, the second is whether a tag element passed in is a legal parent of the contained tag element, the third is whether the widget is a container which can contain other widgets inside, the fourth is whether the widget is able to contain the data binding widgets, and the last one is whether the widget itself is a data binding

widget. Through the common information provided in the program, we can add or modify any widgets to conform to future changes of the PUML specification with less effort.

Widget Bean Description

Each widget bean exposes its access methods through a widget bean description.

The widget bean descriptions are loaded while the toolkit starts up, hence the content of a widget bean could be accessed while running the toolkit. Moreover, the constraints of the attributes embraced in each PUML tag element will also be described inside the corresponding widget bean description. The program can therefore verify the editing attribute result according to the constraints.

4.4.2 The Attribute Constraints

Figure 4-4: The structures for storing attribute constraints and used texts.

The attribute constraints in the toolkit contains two items, one is the “Required”

constraint which describes if an attribute value needs to be set with an non-empty value, the other is the “Unique” constraint which describes if an attribute needs to have an unique value over entire PUML document. Once the “Unique” is set as true, the attribute values must be stored to avoid overlapping and ensure the uniqueness.

The toolkit preserves two tables for storing attribute constraints and used attribute values as depicted in Figure 4-4. Both tables utilize the name of tag element

and the attribute name as a pair to form the reference key. The attribute constraints table stores every attribute constraints while the used attribute value table stores thee attribute value only when the attribute has the “Unique” constraint set as true.

Furthermore, if the attribute has “Unique” constraint set as true, the toolkit automatically generates a unique value when creating a widget on the design canvas.

At the same time, the toolkit does not allow developers input an attribute value which conflicts with any existing attribute value. In this way, the toolkit can prevent possible errors before transforming the PUML document into other formats.

4.4.3 Drag-and-Drop Framework

A drag and drop operation is a data transfer request that has been specified by a gesture with a graphical pointing device, and what the operation does in the background is simply transferring the data from the drag source to the drop target.

There are mainly two scenarios to drag-and-drop components in the toolkit, one is to drag a button from the toolbox onto the design canvas, and the other is to drag a widget from the design canvas onto the toolbox. Since the drag-and-drop framework has already integrated into Java, it is quite easy to add transfer handling mechanism into every visualized components, however, the transferring data still needs customizations, therefore, a string represents the class path of the widget bean is transferred in the first scenario, and a widget object is transferred in the second scenario. The transferring data is designed to contain the least information required for the overall performance. Through the drag-and-drop framework, developers can operate the toolkit without knowing how the data being transferred in the background.

4.4.4 Widget-Generation Framework

On the one hand, the created PUML document can be saved for next time usage;

on the other hand, generating visualized widgets back to design canvas while opening a saved PUML document is required as well. The widget generation framework recursively generates all of the widgets from each tag element, a widget-generation process is not only used in opening a document, the actions such as move, paste, and drag-and-drop widgets are also utilize this process for code-reusing purpose.

Figure 4-5: The process of generating a widget from the PUML tag element.

A widget-generation process example is depicted in Figure 4-5; the first step is to generate a widget bean according to the tag element name. The second step is to set fields of the widget bean according to all available attributes in the tag element.

Following step is to generate a widget user-interface component according to the widget bean and wrap the component inside a widget wrapper at last. The example widget can then be added to its legal parent widget in the design canvas.

4.4.5 Collapsible and Disguisable Widgets

A collapsible widget is allowed to have some child widgets in it, and the child widgets can be visible or invisible according to the options in the visual control pane.

Once the child widgets are hided, the parent widget will adjust its size to the minimum size it allows. It will be look like the widget is collapsed and that is where the word “collapsible” comes from.

The disguisable widget is mainly to indicate the data binding widgets which will not show in the final transformed user-interface. The reason why it shows on the generic user-interface is to make developers using familiar drag-and-drop operations in adding widgets. The data binding widgets can be easily selected and their attributes can be edited in the same way. Therefore, through controlling the visibility of the data binding widgets, we can utilize existing features on the one side and still preserve the outlook of the generic user-interface on the other side.

4.4.6 Smart Position Inference

The layout of a generic user-interface is in a vertical way for fitting into the small screen size of mobile devices. In this vertical layout scenario, smart position inference mechanism is added to facilitate the layout arrangement.

Figure 4-6: The smart position inference area.

While adding a widget onto the design canvas, there are mainly three areas which could be put on. Figure 4-6 depicts these areas with a dashed line circled around and a number marked on each area. Once the developer drag-and-drop a widget to the area marked with n, the widget will be added above “Widget One” in Figure 4-6. In the same way, the widget will be added between “Widget One” and

“Widget Two” while drag-and-drop it to the area marked with o. Obviously, the widget will show up under “Widget Two” while drag-and-drop it to the area marked with p. Although it seems simple to add a widget according to the position above, before, under, or after a certain widget, the insertion action actually requires finding out what widget to insert before and then insert the widget with size and position adjustments. Developers therefore do not need to know what happened in the background, simply drag-and-drop to a position and get an intuitive result is the goal we have achieved.