Figure 5.42: Instantiation of user interface elements in WebML: an excerpt from the WebML metamodel [238]
2. Web applications may communicate with web services51, as discussed earlier in Section2.3.1. There are different technologies that may be used in communicating with web services; the service may be defined formally according to standards such as SOAP [340] and XML-RPC [363], or in a proprietary format using JSON [65].
5.13
User Interface Modelling
As discussed earlier in Section2.3.1, the user interface is a very important aspect of RIAs as their interactivity and richness depends directly on its interface. User interface modellingis supported in IAML to describe the composition and structure of user interfaces, and is an important part of the modelling language.
5.13.1 Existing Approaches in Modelling User Interface Types
WebML defines different types of Content Unitssuch as Entry Units (similar to Input Forms) and
Index Units (similar to Iterator Lists) [51]. However within its UML metamodel, these different types are treated as “black-box plugins to the three existing models, rather than constituents of an independent modeling layer” [238]. To illustrate this design, an except from the WebML metamodel as described by Moreno et al. [238] is illustrated in Figure5.42.
The WebML approach is similar to defining aVisible Typeelement within the WebML metamodel, allowing different types of elements to be loaded through a library. The reliability of the WebML ap- proach is fairly weak52 compared to the UWE approach; by defining atypeof typeString, there is no guarantee that the given type ofContentUnitwill actually exist in the system, and all aspects of the implementation must essentially implement their own type checking system. That is, a metamod- elling environment that implements the WebML metamodel must be extended to identify different
ContentUnitinstances. However, this does solve the issue of defining behavioural semantics, because all of the semantics are moved into third-party plugins.
51Use Case 27:Web Service.
52This can be considered a specific instance of thePrimitive Obsessiondesign anti-pattern discussed by Fowler [100, pg. 81–82], where the differences between different types are expressed via a primitive, rather than through an object type hierarchy. This anti-pattern can result in issues of referential integrity, as there are now two different typing mechanisms in the system.
Figure 5.43: Instantiation of user interface elements in UWE: an excerpt from the UWE meta- model [196, pg. 13]
UWE, on the other hand, defines separate types ofUIElementsfor each type of interface element within the metamodel, such asButtonandText. An excerpt from the UWE metamodel as described by Kroiß and Koch [196] is illustrated in Figure 5.43. Instances of the user interface elements are notated in UWE model instances using stereotypes [196, pg. 22]. UML itself does not provide any standard way of modelling user interfaces, and extensions such as UMLihave been proposed [68].
As these two investigations show, both approaches can be used to model the user interface of a web application. More research is necessary to identify when one approach is beneficial over the other. However, the design of the user interface modelling aspect of IAML is most similar to the UWE approach, where each user interface element is defined as a subtype.
5.13.2 Visible Thing
In IAML, theCompositedesign pattern [118, pg. 163–173] is used to design user interfaces, as illus- trated in the UML class diagram in Figure5.44. Visual elements may be used to compose interfaces, and these elements themselves may be composed of other visual elements. The composite design pat- tern also aligns nicely with the hierarchical modelling approach in IAML, as top-level visual elements can hide the complexity contained within.
TheVisible Thingtype is the abstract type for all visual elements in the language. AVisible Thing may be hidden on the user interface, by modifying the value of thevisibleproperty of the element at either design-time or runtime. Since all visual elements are designed to be renderable to the user, all Visible Thingshave additional events related to user interactivity – such as theonClick and onInput
events discussed earlier in Section5.7 – and are allChangeable (and therefore have a field value). This chapter will briefly introduce each subtype ofVisible Thingwithin IAML; these are discussed in further detail in AppendixI.
It is also necessary to define the way in which a user interface isrenderedto the user. The spatial layout of a user interface is important, so eachVisible Thing also specifies its render order. While this spatial information is placed within the model instance itself, it may be desirable to move this information into a separate layout model in the future to encourage the separation of concerns between the interface layout and the underlying model.
5.13 User Interface Modelling 147
Button
AButtonrepresents a clickable button in the user interface, and is derived from the HTMLBUTTON
element specification [333], If triggering theonClickevent does not change the state of the web appli- cation – for example, it does not modify any databases or interact with any external component – then theButtonmay be rendered as a text hyperlink.
Label
ALabelrepresents a static block of text that is not user-editable, but may still be modified program- matically and triggeronClickevents. This element is derived from the HTMLLABELelement specifi- cation.
Input Text Field
AnInput Text Fieldrepresents a text field that accepts text input from the user, and is derived from the HTMLINPUTelement specification [333].
Input Form
AnInput Form represents a group of related input elements, and is derived from the HTML FORM
element specification [333]. AnInput Form is particularly useful when using a Sync Wireor Set Wire, as discussed earlier in Section 5.9.1. In particular, if aDomain Iterator is connected via one of these wires to an emptyInput Form, the form will be populated with the necessary user interface elements to read or to edit the given iterator instance.
Map
AMaprepresents a geographical area as an interactive map – that is, the map can be navigated from within the browser. Compared to the other definedVisible Things, including theMapmodel element is particularly interesting, as it has no analogy in either HTML 4.01 [333] or the upcoming HTML 5 standards [343]; however, if a platform-independent map element is introduced into an upcoming HTML standard, the IAML metamodel will be automatically forward-compatible. AMapmay contain manyMap Pointsin order to show multiple locations simultaneously.
Map Point
AMap Pointrepresents a single geographical point, whereas aMaprepresents a single geographical area. AMapmay contain any number ofMap Points, all which will be rendered within the current Mapas separate points; however, aMap Pointdoes not need to be contained by aMap, in which case the point is rendered individually. In order to model an indeterminate number ofMap Pointswithin a Map, anIterator Listmay be used as discussed in the next section.
Iterator List
All of theVisible Things discussed so far in this section only support single instances; that is, the number of these elements that may be rendered is defined at design-time, and cannot be controlled
5.13 User Interface Modelling 149
Model Element Sample Representation Button
Input Text Field
Input Form
Label
Map
Map Point
Iterator List
at runtime. AnIterator Listallows for a set ofVisible Thingsto be rendered an arbitrary number of times, controlled at runtime via an instance of theDomain Iteratormodel element.
For example, if an Iterator Listcontains a single Labeland the connected Domain Iteratorhas fiveresults, then fiveLabelswill be rendered at runtime. If the Domain Iteratorisempty, then the Iterator Listwill also be empty.
5.13.3 Sample Representations
A sample rendering for eachVisible Thing subtype is illustrated in Table5.4. In this summary, the visual representations ofMapandMap Pointare those provided by the Google Maps library.
5.13.4 Frame
AFrameis used in IAML to represent a block of content that may be accessed and rendered inde- pendently by a web browser, and as an Actionmay be connected by an ECA Rule to support user navigation. By default, the interface to a Framewill be provided through the combination of web technologies such as HTML and Javascript. However, if therender attribute of theFrameis set to
RSS20, then the content of theFramewill be available as an RSS 2.0 feed53[290] – particularly useful if theFramecontains anIterator Listto populate the contents of the RSS feed.
The concept of a Frameincludes both the concepts of a top-level page, and a block of content within anotherFrame. Top-level pages can also specify a customURLin order to specify the intended URL of theFrame. An important piece of future work is in supporting the definition of sub-frames, and the composition of these with parent Framesin order to support richer web applications. This technique could be used to implement functionality such as wizard-based workflows [328].
By specifying that anFrameis anAction, anECA Rulemay also be used to redirect the browser to a differentFrame. Any incomingParametersto the connectingECA Ruleare therefore passed as Query Parametersto the targetFrame.
Example
Within Ticketiaml, the implementation of theBrowse Eventspage is implemented through the defini- tion of aFrameconsisting of a number of containedVisible Things, as illustrated in the partial model of Figure5.45. Here, anDomain Iteratoris used to populate anIterator Listof matching events via aSet Wire, which then populate a Mapvia anotherSet Wire. This iterator is also restricted via an incoming parameter from anInput Text Field.