UNIVERSIDADE TECNICA DE LISBOA INSTITUTO SUPERIOR TECNICO

CMS-IL: CMS Intermediate Language

Users Guide

Document produced by PhD Student: Joo de Sousa Saraiva (jppmssaraiva@gmail.com) (author) a PhD Supervisor: Alberto Silva (alberto.silva@acm.org)

September 2011

Contents

List of Figures

ii

Listings

iii

Chapter 1 Introduction
The Model-Driven Engineering paradigm has become increasingly popular due to its usage of models as the main artifacts in the software development process, while artifacts such as documentation and source code can be produced from those models by using automated transformations. On the other hand, we are currently witnessing the rise in popularity of a particular kind of web application, Content Management Systems (CMS), which are already typically regarded as software systems critical to the success of organizational websites and intranets. This document presents the CMS Intermediate Language (CMS-IL), a textual language which provides a low level of abstraction over computation concepts (in the sense that it is similar to a programming language), although it is still CMS-oriented and platform-independent. The objective of this language is to provide a mechanism, independent of any particular CMS implementation, that can be used by technical stakeholders to (1) address low-level computation aspects, and (2) deploy a website model in any CMS platform (assuming, of course, that the platform can interpret CMS-IL models). Furthermore, the language also allows for its extension, in order to address an organizations specic requirements and to support the modeling of more complex web applications. CMS-IL was structured so that it is not mandatory that a single designer have the skills to create both WebSite Template and CMS-based Toolkit models. This language considers the following roles: The Toolkit Developer, who species Toolkits using programming language-like elements, but still in a platform-independent manner; The WebSite Template Developer (usually designated just as Template Developer, for text simplicity), who models a WebSite Template;

1.1. CONVENTIONS USED The Web Designer, who denes visual themes and graphics for that same WebSite Template; The WebSite Creator, who instantiates the various elements dened in the WebSite Template. These roles are shown in Figure ??.

Figure 1.1: The roles and artifacts considered by CMS-IL.

1.1

Conventions Used

The following conventions are assumed through the remainder of this Users Guide. CMS-ILs abstract syntax is described in this document using UML, because: (1) although the language does not use UML as a metamodel, it is nevertheless possible to use UML to illustrate each of CMS-ILs metalevels; and (2) it is expected that most readers are familiar with UMLs class diagrams, due to its widespread use nowadays. When the text mentions a name with uppercase initials, it is referring to a CMS-IL concept, while a name with lowercase initials refers to a generic term. As an example, the term WebSite is used to refer to the Structure views WebSite concept in particular, while the term website is used to refer to the website or system that is being modeled. It should also be noted that, for the remainder of this Guide (and for simplicity reasons), the terms website and web application are considered to be synonyms.

Chapter 2 CMS-IL Elements

Figure 2.1: The relationship between CMS-IL models. A WebSite Template (sometimes just called Template, for simplicity) is a model that reects the intended websites structure and behavior; this Template is modeled using CMS-oriented elements such as Role, Dynamic WebPage, WebComponent that are provided by CMS-IL.

On the other hand, a Toolkit allows the addition of new modeling elements to the set of elements that are available for modeling a WebSite Template, namely by specifying a domain model, user interface, and corresponding behavior. A WebSite Template can then reference a Toolkit (or a set of Toolkits), making the Toolkits elements available for use in the Template model. Furthermore, a Toolkit can also reference other Toolkits, enabling scenarios in which a Toolkit A renes and/or extends functionality dened in a Toolkit B. Finally, the elements of a WebSite Template can be annotated, by means of a WebSite Annotations model (or just Annotations). This model decorates a WebSite Template, allowing developers to specify CMS-specic properties without polluting the Template with platform-specic details. Thus, from a practical perspective, CMS-IL developers do not view two dierent models (the Template and the Annotations), but rather a single model that results from combining those two models (i.e., a model that is the result of extending the Template with the Annotations). Before starting the description of CMS-IL, it is important to highlight that WebSite Templates and Toolkits are located in dierent metalevels. While WebSite Templates are meant to create abstractions (i.e., models) of concrete web applications by using CMS-oriented elements, Toolkits use generic modeling elements to create new CMS-oriented modeling elements. Because some Toolkit concepts are also specializations of WebSite Template concepts (and so instances of those Toolkit concepts are automatically considered as instances of the corresponding WebSite Templates concepts), Template Developers can then use those Toolkit concepts to create WebSite Templates in the same manner as when using the predened Template modeling elements. The architecture of CMS-IL illustrated in Figure ?? considers the following metalevels: The metalevel IL3 denes all of CMS-ILs Toolkit modeling concepts, in the Toolkit Modeling model (which, in turn, is the metamodel for the Toolkit model in IL2). Stakeholders cannot make any changes on this metalevel; IL2 is the metalevel that provides the WebSite Template Modeling and WebSite Annotations Modeling models, which are used as the metamodels for WebSite Template and WebSite Annotation models, respectively. Furthermore, it is in IL2 that Toolkit Developers can specify their Toolkit models, by creating instances of the modeling concepts dened in IL3. Of course, the WebSite Template Modeling and WebSite Annotations Modeling models cannot be changed by anyone; The IL1 metalevel is where WebSite Template Developers and Web Designers create WebSite Template and WebSite Annotations models. These models are specied by using the WebSite Template Modeling and WebSite Annotations Modeling concepts 4

2.1. WEBSITE TEMPLATE

Figure 2.2: Metalevels considered by CMS-IL. dened in IL2, as well as the Toolkit model elements dened in IL2 (which, in turn, are themselves instances of the concepts dened in IL3); IL0 is the metalevel in which the WebSite Creator operates, namely by creating instances in a particular CMS installation of the elements that were dened in IL1s WebSite Template and WebSite Annotations models. This will typically be performed in an automated manner, by using a CMS-specic mechanism that can map model elements to instances, although it should be considered that the WebSite Creator may have to manually adjust some CMS-specic details that are not contemplated by the mapping operation. The remainder of this chapter is dedicated to describing these models WebSite Templates and Toolkits in greater detail as well as the Annotations feature.

2.1

WebSite Template

CMS-IL provides a set of generic modeling elements that WebSite Template Developers can use to dene their Templates for CMS-based websites. A WebSite Template is dened according to a set of views (illustrated in Figure ??), namely:

2.1. WEBSITE TEMPLATE The Structure view, which denes the structure of the web application, namely its pages and their components; The Roles view, specifying the responsibilities that the web application expects of its users; The Permissions view, modeling what the web applications roles are allowed to do; The Users view, which denes particular users that are considered important to the modeled web application (and thus should be available immediately after deploying the model to the CMS); The Languages view, which deals with localization and the languages that the web application should have available; The Artifacts view, where the Developer can dene a set of language-agnostic artifacts (strings and les) that will be available in the web application; The Contents view, which species content to be displayed by the web applications structural elements (namely content provided by the Artifacts view); and The Visual Themes view, which species the graphical layout and properties of the web applications various structural elements.

Figure 2.3: The views involved in the denition of a WebSite Template. The bootstrapping views are not mandatory for the modeling of a Template, and should only be dened when Template Developers have a priori content that should be available in any web application that is an instance of the modeled Template. The next subsections provide further details on these views and on how to model WebSite Templates.

2.1.1

Structure View

The Structure view enables the modeling of the websites structure, a factor that is usually paramount in the users acceptance of a website. Figure ?? illustrates the concepts that are used when specifying the Structure view.

2.1. WEBSITE TEMPLATE

Figure 2.4: Abstract syntax for the WebSite Templates Structure view. Modeling the website begins with the WebSite concept, which represents the system/website that is being modeled. This concept denes the following attributes: Name (string): The name of the website that is being modeled (e.g., My Personal WebSite); Description (string): An optional description of the website being modeled. Listing ?? provides a simple example of WebSites concrete syntax, as it depicts a WebSite called My Personal WebSite. Listing 2.1: Concrete syntax for WebSite.
1

WebSite My Personal WebSite

After dening the WebSite itself, the Template Developer will use the Dynamic WebPage concept. A WebSite contains an ordered set of at least one Dynamic WebPage; one of these Dynamic WebPages will be the websites HomePage. This set must be ordered because these Dynamic WebPages will typically be presented in a hierarchical tree mechanism, in which alphabetical sorting by the Dynamic WebPages name is often not adequate. Dynamic WebPages can themselves contain additional Dynamic WebPages (also in ordered sets) via the Dynamic WebPage Child concept, allowing Template Developers to specify 7

2.1. WEBSITE TEMPLATE a hierarchy of Dynamic WebPages for the website. The Dynamic WebPage concept denes the following attributes: Name (string): The name of the Dynamic WebPage (e.g., Home, Photo Gallery); Aliases (set of strings): A (possibly empty) set of strings that provide alternative names for the page (e.g., an About page can also have an alias Contacts). This is not merged with Name because the latter has the responsibility of being the pages canonical name (i.e., its authoritative name). By default, a Dynamic WebPage can be viewed by anyone (including anonymous users). If this is not desired, the Template Developer must specify a set of permissions for the Dynamic WebPage, in the Permissions view (see Subsection ?? for further details). Listing ?? illustrates the concrete syntax for Dynamic WebPage: (1) Line ?? depicts a Dynamic WebPage, Home, that is a HomePage; and (2) Line ?? depicts a regular Dynamic WebPage, About Me. Both of these WebPages are included in the WebSite that was previously dened in Listing ??. Listing 2.2: Concrete syntax for Dynamic WebPage.
1 2 3

WebSite My Personal WebSite has HomePage Home Page About Me

Dynamic WebPages can also be related to each other by two kinds of relationship, Dynamic WebPage Child and Dynamic WebPage Template. The Dynamic WebPage Child relationship enables the Template Developer to establish parent-child relationships (in an ordered manner) between Dynamic WebPages, allowing the modeling of the WebSites Dynamic WebPage hierarchy in a tree-like manner. This relationship carries the semantics of composition, in that the removal of the parent Dynamic WebPage will cause the removal of all child Dynamic WebPages. Listing ?? illustrates the concrete syntax for the Dynamic WebPage Child concept, which takes place between the Home and About Me Pages (in line ??). Listing 2.3: Concrete syntax for Dynamic WebPage Child.
1 2 3

WebSite My Personal WebSite has HomePage Home Page About Me child of Page Home

A Dynamic WebPage Template is another kind of relationship between two Dynamic WebPages, the template and the duplicate. This relationship allows the Template Developer to specify that the duplicate will have the same visual structure as the template. 8

2.1. WEBSITE TEMPLATE This relationship is transitive, allowing the visual structure of a Dynamic WebPage to be duplicated among several other Dynamic WebPages while keeping the models design relatively simple. However, it is an error to model such Templates in a circular manner (e.g., Page A duplicating Page B, and Page B duplicating Page A), because otherwise the template specication could become ambiguous. The eects of establishing a Dynamic WebPage Template relationship between a template Dynamic WebPage and a duplicate Dynamic WebPage are the following (the concepts that are mentioned in this list will be explained further down the text of this guide): All the Containers in the template are replicated to the duplicate; The WebComponents that are present in the template are not replicated to the duplicate. Listing ?? illustrates the concrete syntax for the Dynamic WebPage Template concept; this takes place between the Home and About Me Pages (in line ??). Listing 2.4: Concrete syntax for Dynamic WebPage Template.
1 2 3

WebSite My Personal WebSite has HomePage Home with (. . . ) Page About Me follows layout of Page Home with (. . . )

While modeling the WebSite and its Dynamic WebPages, the Template Developer can also model each Dynamic WebPages layout and components. Within each Dynamic WebPage there must be a set of Containers. The Container is a concept that represents an area, within its Dynamic WebPage, where WebComponents will be placed. This concept denes the following attributes: Name (string): The name of the Container (e.g., Top, Bottom, Left); Left (measure): The distance from the left border of this Container to the left border of the parent Dynamic WebPage. Specied as a size measure, the kind of which is identied by the values sux (e.g., percentage is indicated by %, pixels as px, points as pt, or other size measures that are acceptable by a web browser); Top (measure): The distance from the top border of this Container to the top border of the parent Dynamic WebPage, specied as a size measure; Width (measure): The width of this Container, specied as a size measure; Height (measure): The height of this Container, specied as a size measure. Listing ?? illustrates the concrete syntax for Container, in lines ????. Each Container will be used to hold an arbitrary number of WebComponents. A WebComponent is a concept that represents the CMSs functionality, which users can see 9

2.1. WEBSITE TEMPLATE Listing 2.5: Concrete syntax for Container.

WebSite My Personal WebSite has HomePage Home with Container Banner at (22%, 1%, 77%, 10%) Container Navigation Bar at (1%, 1%, 20%, 98%) Container Body at (22%, 12%, 77%, 87%)

and with which they will possibly interact (e.g., a GuestBook, some HTML text). The WebComponent concept denes the following attribute: Name (string): The name of the WebComponent that is being modeled (e.g., My Blog, My Photos). The WebSite Template perspective of CMS-IL denes two kinds of WebComponents, Standard WebComponent and Custom WebComponent. A Standard WebComponent can be regarded as a strongly-typed WebComponent (e.g., a Forum, a Blog) that will be available in most CMS systems. Because most WebComponent details will be handled by the CMS system itself, the Standard WebComponent concept denes no attributes. CMS-IL denes the following kinds of Standard WebComponents: HTML Image Links Portal Tree BreadCrumb Announcements Events Blog Forum GuestBook Poll Survey

Additionally, a Custom WebComponent is a WebComponent whose type is manually specied, as a string of characters, by the Template Developer. This concept denes a single attribute: Type (string): The kind of WebComponent that this model element is supposed to represent (e.g., PodCast Receiver, WebTV Receiver). It is usually a good idea for Template Developers to use Standard WebComponents whenever possible, and also to only use Custom WebComponents when there are no Standard

10

2.1. WEBSITE TEMPLATE WebComponents that are suitable for their purposes (or when they are absolutely sure that the target CMS will be able to correctly interpret the string that is provided in the Type attribute). Finally, the WebSite, Dynamic WebPage, WebComponent, and Container concepts all inherit from another abstract concept, Structural Element. This concept is not represented in Figure ?? for simplicity, but is referenced in other views to enable relationships with structural elements (i.e., elements that inherit from Structural Element). Listing ?? provides an example of the concrete syntax for WebComponents: (1) lines ?? and ?? depict two Standard WebComponents, each included in its own WebPage (the former is explicitly dened within a Container, while the latter is also placed in a Container but its WebPage follows the layout of another WebPage); and (2) line ?? illustrates a Custom WebComponent. Listing 2.6: Concrete syntax for WebComponents.
1 2 3 4 5 6

HomePage Home with Container Body at (22%, 12%, 77%, 87%) with WebComponent My Blog of Standard type Blog WebComponent My TV Viewer of Custom type WebTV Receiver Page About Me follows layout of Page Home with WebComponent My Blog of Standard type Blog in Container Body

It is important to note that the order of elements is not explicitly represented in the syntax, but is instead determined by the order in which each element namely instances of Dynamic WebPages and WebComponents is declared within its parent element.

2.1.2

Roles View

The Roles view describes the various kinds of expected responsibilities that users are expected to have when interacting with the CMS-based web application. It denes two concepts, Role and Role Delegation: the former models those expected responsibilities, while the latter species whether such responsibilities can also be played out by other Roles. Figure ?? illustrates these concepts.

Figure 2.5: Abstract syntax for the WebSite Templates Roles view.

11

2.1. WEBSITE TEMPLATE As was previously mentioned, a Role represents a certain kind of responsibility (with a corresponding set of rights) that the modeled web application expects from its users (e.g., a Role can be used to model the responsibility of managing a document repository). This concept has the following attributes (their data types are specied in parenthesis): Name (string): The Roles name. There must not be two Roles with the same name; Type (Role Type): The type of the Role. It assumes one of the following values: Administrator: The Role is considered as a CMS administrator. Although this kind of Role can delegate (or be delegated) responsibilities, most CMS systems tend to allow administrators to do anything at all, so it is not recommended to establish Role Delegations with Administrator Roles; Anonymous: The Role is anonymous (i.e., it represents users that have not authenticated themselves with the CMS system). An Anonymous Role does have some caveats, namely it cannot delegate or be delegated responsibilities; Regular: The Role is just a plain CMS role, without any particular traits. By default, the value of this attribute is Regular. Listing ?? illustrates the concrete syntax for the Role concept. More specically, lines ??, ??, and ?? respectively illustrate regular, administrator, and anonymous Roles. Listing 2.7: Concrete syntax for Template Role.
1 2 3 4 5

Role ARegularRole Role AnAdministrationRole is Administrator Role AnAnonymousRole is Anonymous

On the other hand, a Role Delegation is a very simple concept that establishes a delegation of responsibilities between two Roles, (1) the delegator, which is the Role that delegates its responsibilities, and (2) the delegatee, which is the Role that assumes those responsibilities. There are some notes and constraints regarding the usage of Role Delegations, namely: A Role Delegation cannot involve an Anonymous Role, either as a delegator or as a delegate; An Administrator Role can be involved in a Role Delegation, although this is not a recommended practice; Although CMS-IL does not forbid circular delegations (e.g., Role A delegating to Role B, and Role B delegating to Role A), this is usually not recommended because 12

2.1. WEBSITE TEMPLATE it would make such Role Delegations become redundant (and most CMS systems tend to forbid such circular delegations anyway). Designers using this practice are encouraged to revise their models, either by collapsing those Roles into a single Role, or by removing such Role Delegations. Listing ?? provides an example of the representation for this concept, as it illustrates a Role Delegation relationship between two regular Roles (in which the Role Manager shares its responsibilities with the Role Secretary, and so any Secretary will eectively have the same authority to perform actions as any Manager). Listing 2.8: Concrete syntax for Role Delegation.
1

Role Manager delegates to Secretary

2.1.3

Permissions View

The Permissions view can be considered as establishing a mapping between the websites structure and its roles. It denes two concepts, Dynamic WebPage Permission and WebComponent Permission, which enable the creation of RoleDynamic WebPage and RoleWebComponent links, respectively. Figure ?? provides an illustration of these concepts.

Figure 2.6: Abstract syntax for the WebSite Templates Permissions view. A Dynamic WebPage Permission determines the actions that a Role can perform over a Dynamic WebPage. It has the following attributes: View (boolean): Whether the Role can view the Dynamic WebPage. The default value of this attribute is True; Congure (boolean): Whether the Role can set the Dynamic WebPages CMS-dependent properties (e.g., its name or its caching time). The default value of this attribute is False; 13

2.1. WEBSITE TEMPLATE Manage Child Pages (boolean): Whether the Role can manage this Dynamic WebPages child pages, namely create new child pages or delete existing ones. The default value of this attribute is False; Manage WebComponents (boolean): Whether the Role can manage the Dynamic WebPages WebComponents (i.e., add WebComponents to it, congure the permissions of its WebComponents, or delete existing WebComponents). The default value of this attribute is False. Listing ?? depicts the concrete syntax for a Dynamic WebPage Permission object, as lines ???? specify all the permission values between a Role (ARegularRole) and a Dynamic WebPage (ADynamicWebPage). Permissions that are not explicitly specied assume their default value. Listing 2.9: Concrete syntax for Dynamic WebPage Permission.
1 2

Role ARegularRole can (view, manage WebComponents of) Page ADynamicWebPage Role ARegularRole cannot (congure, manage child pages of) Page ADynamicWebPage

On the other hand, a WebComponent Permission determines the actions that a Role can perform over a WebComponent. It has the following attributes (very similar to the attributes of Dynamic WebPage Permission): View (boolean): Whether the Role can view the WebComponent. The default value of this attribute is True; Congure (boolean): Whether the Role can set the WebComponents CMS-dependent properties (e.g., its name or its caching time). The default value of this attribute is False; Edit Content (boolean): Whether the Role can edit the WebComponents contents (e.g., change HTML, add new forum posts). The default value of this attribute is False; Manage (boolean: Whether the Role can manage the WebComponent (i.e., change its relationships to other elements, such as moving the WebComponent to a dierent Container, or changing its order within the parent Dynamic WebPage) without the requirement of being able to congure it (e.g., set the number of posts to show in a blog). The default value of this attribute is False. Listing ?? depicts the concrete syntax for WebComponent Permission: Lines ???? specify most of the permission values for a WebComponent Permission between a Role (ARegularRole) and a WebComponent (My Blog). However, the Manage permission is left to its default value (False); and

14

2.1. WEBSITE TEMPLATE Lines ???? specify some permission values for a WebComponent Permission between ARegularRole and the Forum WebComponent. Again, unspecied permissions assume their default value. Listing 2.10: Concrete syntax for WebComponent Permission.
1 2 3 4 5

Role ARegularRole can (view, edit content of) WebComponent My Blog Role ARegularRole cannot congure WebComponent My Blog Role RegularRole can edit content of WebComponent Forum Role RegularRole cannot congure WebComponent Forum

2.1.4

Users View

The Users view is responsible for identifying any relevant CMS users that should be available whenever the CMS-IL model is deployed, as well as their Role assignments. A typical example could be an administrator user other than the default one that most CMS systems dene out-of-the-box. It should be noted that this view is optional, and it is useful only for bootstrapping the web applications operation after the CMS-IL model is deployed. This view denes two concepts, User and User Assignment: the former species a CMS user itself (a specic person that will interact with the modeled web application), while the latter models the assignment between a User and a set of Roles. Figure ?? illustrates the concepts of the Users view.

Figure 2.7: Abstract syntax for the WebSite Templates Users view. As stated in the previous paragraph, a User represents a specic person that will interact with the modeled web application. This concept has the following attributes: Given Name (string): The users given name (or rst name, as it is known in western cultures); Family Name (string): The users family name (or last name); Email (string): The users e-mail address (most CMS systems require that registered users provide a valid e-mail). Although most CMS systems require a user to provide a password that is known only to them, the User concept denes no Password attribute because of its sensitive and condential nature. 15

2.1. WEBSITE TEMPLATE The reason why User does not dene a Name attribute, but rather two attributes Given Name and Family Name, is that some CMS systems actually dierentiate between these two kinds of name, most likely so that they can provide a more familiar environment to the user (e.g., by displaying a message Hello, John!, which feels more personal and familiar because it treats the user on a rst name basis than the message Hello, John Doe.). Furthermore, Given Name and Family Name are named as such in order to make the User concept adequate for non-western cultures, in which the Family Name usually comes before the Given Name. This explicit separation allows the CMS to correctly identify the persons family and given names (e.g., for the Chinese name Yao Ming, the family name is Yao, and not Ming as most western cultures would assume). To address this A issue, the Users syntax supports the same rules as L TEXs BIBTEX, namely (a) the usage of western rules Given Name followed by Family Name to represent the Users name, unless (b) a comma (,) is used, in which case the Family Name comes before the comma and the Given Name comes afterward. These rules are especially important when parsing a CMS-IL model, as they remove the ambiguity that underlies typical name parsing. Listing ?? provides an example of the concrete syntax for the User concept. More specifically, it illustrates a User named John Doe (Given Name is John and Family Name is Doe). Listing 2.11: Concrete syntax for User.
1

User John Doe (john.doe@company.com)

A User Assignment is a simple concept that establishes a connection between (1) a User, representing the person that is to assume some responsibilities, and (2) a Role that represents the responsibilities which will be assumed by the User. As is the case in most CMS systems, it is possible for a User to be assigned to more than one Role. Listing ?? provides an example of a User Assignment, which takes place between the User John Doe and one of the Roles (in this case, Manager) that the User is to perform. Listing 2.12: Concrete syntax for User Assignment.
1

User John Doe has the Role Manager

It should be noted that the User Assignment represented in Listing ?? does not explicitly represent the Email property, because in this example we assume that there is only one User with Given Name and Family Name as John and Doe, respectively. If this was not the case, and there was more than one such User (a situation that, in practice, is not 16

2.1. WEBSITE TEMPLATE uncommon), then their respective Email addresses would have to be represented, in order to remove any possible ambiguity between those Users (as an e-mail address is typically used only by a single person). Another way to solve this problem would be to assign the User to a CMS-IL alias (as explained in Subsection ??), and then use that alias to assign the User to the Role.

2.1.5

Languages View

The Languages view addresses a part of CMS-ILs content localization issues, by enabling the specication of what languages will be supported in the web application. It denes a single concept, Language, which is used to model the various languages to be considered (e.g., English, Portuguese, Spanish). Figure ?? provides a simple illustration of the concepts for this view.

Figure 2.8: Abstract syntax for the WebSite Templates Languages view. The Language concept has the following attributes: Name (string): The name of the Language, according to its own language (so that users uent in the language can immediately recognize it); ISO Name (string): The ISO name of the Language (e.g., pt-pt, en-uk). This is the language identication code (according to Best Current Practice 471 ), which in turn is also typically used by web browsers when making requests to the web application (by specifying the HTTP header Accept-Language2 ); Order (integer): The Languages order in the context of the web application. More specically, this establishes an ordered set of Languages for the web application, which in turn can be used by the supporting CMS system to choose the language in which the web applications elements (and content) will be displayed to the user. Listing ?? illustrates two examples of the concrete syntax for the Language concept: (1) the example in line ?? denes the English Language, while (2) line ?? corresponds to the Portuguese Language. Like in the Roles view, the order of each Language is implicitly specied by the order in which it is declared in the model; in other words, if English was
1 2

http://www.rfc-editor.org/rfc/bcp/bcp47.txt http://www.w3.org/International/questions/qa-accept-lang-locales

17

2.1. WEBSITE TEMPLATE declared after Portuguese, then their Order attributes would assume the values 2 and 1, respectively. Listing 2.13: Concrete syntax for Language.
1 2 3

Language English (en-uk) Language Portuguese (pt-pt)

The reason why this view is so simple (i.e., it denes just a single concept) is that it is used only to identify the regions/cultures that are considered relevant for the web applications purpose (namely by dening their names and ISO codes). It will be up to the CMS system itself to provide the corresponding UI text translations, and to the Contents view (explained in Subsection ??) to provide the localized contents.

2.1.6

Artifacts View

The Artifacts view allows the Template Developer to provide some a priori artifacts (as the name suggests), namely strings and les. These artifacts can then be used in the Contents and Visual Themes views, described in the next subsections. Figure ?? illustrates the concepts for the Artifacts view.

Figure 2.9: Abstract syntax for the WebSite Templates Artifacts view. This view is modeled by specifying Artifacts. An Artifact is an object that represents some content (e.g., the string Hello!). This concept has the following attribute: 18

2.1. WEBSITE TEMPLATE Name (string): The Artifacts name. Furthermore, each Artifact is categorized as either a String or a File. A String is a simple concept that consists of an ordered set of characters, just like strings in typical programming languages. The String concept denes the following attribute: Value (string): The value of the String. CMS-IL contemplates two dierent kinds of String, (1) Placeholder Strings and (2) Absolute Strings. Both kinds of String support the usage of escape characters (i.e., characters that change the meaning of the characters that follow). To facilitate the specication of Strings by Template Developers, CMS-IL adopts the escape semantics that are typically found in programming languages: the character \ is used to indicate that the following character should be escaped (i.e., not interpreted as-is), and any occurrence of \\ is interpreted as regarding the character \ itself. An Absolute String is a String that can contain only certain escape character sequences (namely the ones to include string terminator characters: \\, \", and \), and all other characters are interpreted as-is. An example of this dierence in character sequences is that Hello\n contains 7 characters (\n counts as 2 characters), but \Hello\ ! contains 8 characters (as \ counts only as a single character, ). Listing ?? provides an example of the concrete syntax for this concept: Line ?? illustrates an Absolute String containing a # (a placeholder character) that is interpreted as-is, and an escape sequence \\ that is interpreted as \; Line ?? illustrates another Absolute String that contains two escape sequences, \" and \, which are respectively interpreted as " and ; Listing 2.14: Concrete syntax for Absolute String.
1 2

String PasswordRequirements is absolute Your password must include the characters # and \\ String PasswordForbiddenChars is absolute Your password must NOT include the characters \ or \

On the other hand, a Placeholder String not only supports the escape character sequences of Absolute String, but also increases the range of supported sequences (e.g., with \t, \n, \b, and other sequences typically supported by programming languages). Furthermore, it enables the usage of named placeholders, which are special markers, with a name (surrounded by #{ and }), that are used to pinpoint particular positions in a String. These placeholders can then be used to dynamically include text in the corresponding string, whenever the String is referenced in other CMS-IL views. A typical example of this feature would be the replacement of the placeholder user, in the string

19

2.1. WEBSITE TEMPLATE Welcome, #{user}!, with the given name of the CMS user that is currently authenticated (if any), in order to obtain a string like Welcome, Jack!. Listing ?? illustrates a Placeholder String named WelcomeMessage, which contains a placeholder, #{user}, and two \n escape characters. Listing 2.15: Concrete syntax for Placeholder String.
1

String WelcomeMessage is Welcome, #{user}!\n\nPlease select an action:

As for the remaining kinds of Artifact, a File represents a le in the storage medium in which the CMS system operates; even if the storage medium does not support the concept of les (e.g., a cloud-based environment such as Microsofts Azure which uses binary large objects, or blobs), it is customary for such environments to provide some similar data-storage mechanism. This concept denes the following attribute: FileName (string): The name of the le that is being represented. CMS-IL contemplates the following kinds of File: (1) the Empty File, as the name indicates, consists of a le without any content (which can be useful to ag certain conditions, such as Application successfully installed and congured ); (2) the File From URL consists of a le whose initial contents (i.e., its contents when the CMS-IL model is deployed to a CMS) should be obtained from the specied SourceURL; (3) the Text File is a le with text content (the content is specied in the same manner as a Placeholder String); and (4) the Binary File is a le, similar to Text File, but it has binary contents, which are specied in Base64 encoding (in order to be readable and writable as text in a CMS-IL model, without requiring encoding schemes such as UTF-8). It should be noted that, although there is a File concept, CMS-IL does not provide the concept of directory. This is because the manner in which les (or other content) are persisted should typically be considered as an internal detail of the CMS system (in order to promote abstraction from implementation details). Furthermore, most CMS systems provide some mechanism that supports the storage of key-value pairs (e.g., a NoSQL implementation such as Apache CouchDB3 , to which the File concept can be mapped by storing the pair <le name, le content>. However, it is not as common for such mechanisms to support namespaces (or similar), which would be necessary to support directories; although it would be possible to specify the key as a concatenation of the directory name and the le name, that solution could then lead to other problems, such as complicating index or search operations. Thus, by not providing a directory concept, it becomes easier to implement a CMS-IL model interpreter mechanism if the target CMS does not provide a traditional le system-based storage medium.
3

http://couchdb.apache.org

20

2.1. WEBSITE TEMPLATE Listing ?? provides the concrete syntax for the various kinds of File: Line ?? depicts an Empty File, whose Name indicates that the website represented in the CMS-IL model has been congured; Line ?? represents a File From URL that fetches its initial contents from the specied URL (in this case, a le containing the text for an end-user license agreement); Line ?? presents a Text File containing a simple string Hello; and Line ?? presents a Binary File that contains a Base64-encoded set of octets. Listing 2.16: Concrete syntax for Files.
1 2 3 4 5 6 7

File website has been congured.txt File license.txt from http://www.mycmsdomain.com/eula.txt File text le.txt with text content Hello File binary le.txt with binary content 0a5b=

2.1.7

Contents View

The Contents view can be used to provide the initial contents for the website, namely through the usage of artifacts (dened in the Artifacts view). The concepts for this view are illustrated in Figure ??.

Figure 2.10: Abstract syntax for the WebSite Templates Contents view. Modeling in this view starts with dening instances of the Content concept, which represents some string that will be shown to a user browsing the website. A typical example is the text in a websites banner (e.g., My Website) or the welcome message that appears 21

2.1. WEBSITE TEMPLATE on the websites starting page (e.g., Welcome to my homepage!). This concept denes the following attributes: Name (string): The name of the content. Contents that are contained within other Contents must have a name. For other Contents, specifying a name is optional; Value (string): The content text itself. A Content can itself be a container for other Contents. A typical example would be a Forum Thread, with a Content corresponding to a Post and the contained Contents corresponding to replies to that Post. Note that there is no predened structure for a Content element, and so its interpretation will depend on the structural element(s) to which the Content is assigned. Listing ?? presents some concrete syntax examples for the Content concept: Line ?? illustrates a simple English Content that contains no other Contents; and Lines ???? also depicts an English Content, but now containing a small set of simple Contents. Listing 2.17: Concrete syntax for Content.
1

Content Lorem Ipsum 1 in English is Consulted perpetual of pronounce me delivered. Too months nay end change relied who beauty wishes matter. Content Lorem Ipsum 2 in English is You folly taste hoped their above are and but. Dwelling and speedily ignorant any steepest. contains ( Content is Drawings me opinions returned absolute in. contains Content is Early to weeks we could. Content is Cheerful but whatever ladyship disposed yet judgment. )

2 3 4 5 6 7 8 9 10 11

It is important to elaborate on two particular aspects regarding the examples presented in Listing ??. The rst aspect regards the Content Value strings dened after the is token and delimited by the " token on both sides of the string which are present in most of the examples provided. A Contents Value is specied as a regular text string (written as typical Placeholder Strings) in the aforementioned manner; everything (even whitespace) included between the " tokens is a part of the Value. The only caveat is that the " token itself cannot be included in the string (although it can be escaped, by writing \"). The nal aspect, which is also related to the " token delimiting the Contents Value, regards the indentation used in the value depicted in lines ????. The indentation of each line in a Content is determined by using the same rules as Pythons multi-line 22

2.1. WEBSITE TEMPLATE docstrings 4 . More specically, this is done by the following process: (1) considering the set of all non-blank lines in the Content, determine its minimum indentation; and (2) remove that same indentation from all lines in the Content. Thus, lines ???? are not really indented, because their minimum indentation (two spaces) is removed from every line in the Content. However, because each line has the same indentation as the others, they are all considered to be starting at the beginning of the line (i.e., with no indentation whatsoever). The Content Assignment concept allows Template Developers to specify the contents to be shown in (1) WebComponents, or in the WebSites (2) banner or (3) footer. The reason for supporting these last two assignments considering that the Structure view does not contemplate the existence of the WebSites banner or footer is that, although CMS administrators are usually unable to change the websites banner or footer itself (unless they have some technical know-how regarding the systems programming infrastructure), typically they are able to change the contents of the banner and footer (i.e., the text to be displayed in these sections of the Dynamic WebPage). Of course, it is important to keep in mind that the interpretation of an assigned Content actually depends on the assignments target (e.g., a Content assigned to a Forum WebComponent will be interpreted in a dierent manner than if it were assigned to an HTML WebComponent). Listing ?? depicts the concrete syntax for the Content Assignment concept. More specifically, lines ?? and ?? show Content Assignments that take place between a Content and an HTML WebComponent and between a Content and the WebSites banner, respectively (the denition of Contents Lorem Ipsum 4 and Lorem Ipsum 5 is not provided for simplicity). Listing 2.18: Concrete syntax for Content Assignment.
1 2

Content Lorem Ipsum 4 is the Content for WebComponent Introduction Text Content Lorem Ipsum 5 is the Banner Content

It is also possible to establish bidirectional Content Equivalence relationships between two or more Contents. This equivalence relationship is important when Contents are localized (i.e., they are written in specic Languages), as it becomes necessary to indicate that a set of Contents, although written in dierent Languages (such as Portuguese and English), are semantically equivalent to one other. Listing ?? illustrates a Content Equivalence relationship between two Contents, in Portuguese and English.
4

Python Documentation, PEP 257: Docstring Conventions, <http://www.python.org/dev/peps/ pep-0257/#handling-docstring-indentation>

23

2.1. WEBSITE TEMPLATE Listing 2.19: Concrete syntax for Content Equivalence.
1 2

3 4

Equivalence between Content Lorem Ipsum 3en in English is I asked God for a bike, but I know God doesnt work that way. So I stole a bike and asked for forgiveness. and Content Lorem Ipsum 3pt in Portuguese is Pedi a Deus uma bicicleta, mas sei que Ele no funciona a assim. Ento roubei uma bicicleta e pedi perdo. a a

Furthermore, a CMS-IL Content can also use any number of Artifacts that were dened in the Artifacts view. Contents can use an artifact in one of the following manners: (1) if the Artifact is a String, then its Value is included into the Contents Value; (2) otherwise, the Artifact should be a File and it can either a) be linked to, or b) have its contents included into the Contents Value (just like a String). Listing ?? provides an example of a Content that references two Artifacts, license.txt and WelcomeMessage (the tokens used will be explained at the end of this section). Listing 2.20: Concrete syntax for a Content referencing Artifacts.
1 2 3 4 5

Content License in English is >= WelcomeMessage user:Jack < License follows: >= license.txt < The full text of this license is also available at: > license.txt <

Finally, a Content can declare aliases for variables that are provided by the CMS, in order to then include the values of those variables into the Contents Value (in a manner similar to a Contents usage of String Artifacts). This is done via the CMS Variable Alias concept, which assigns an Alias to a CMS Variable; the CMS Variable, in turn, depends: (1) on the target(s) to which the Content is meant to be assigned (e.g., the WebSites banner may provide CMS Variables, such as the current users GivenName, that the footer does not); and (2) on the target CMS (e.g., the banner for a specic CMS may provide CMS Variables that another CMS does not). Although this dependence on the target CMS could make a CMS-IL model be considered as not being platform-independent (because the Template Developer would have to be aware of what is the models target CMS, and the variables that it provides), this problem can be addressed by using Annotations (which are explained in Section ??) to specify that the Contents target (e.g., the WebSites banner) must provide those CMS Variables, thus ensuring that the CMS-IL model is still platform-independent. The CMS Variable concept denes the following attributes: Alias (string): The local name (i.e., valid for the current Content only) that is being given to the CMS-provided value; 24

2.1. WEBSITE TEMPLATE CMS Variable (string): The CMS-provided value that is being referenced. Listing ?? illustrates the denition and usage of CMS Variable Aliases: (1) line ?? declares an alias, userFirstName, for the CMS Variable CurrentUser.GivenName; (2) line ?? directly outputs the value of the userFirstName Alias, which in turn outputs the value of the CurrentUser.GivenName CMS Variable; and (3) line ?? uses the value of the Alias userFirstName as input for the user placeholder in a WelcomeMessage Artifact. Listing 2.21: Concrete syntax for CMS Variable (denition and usage).
1 2 3 4 5

Content WelcomeMsg in English has variables (CurrentUser.GivenName as userFirstName) is Welcome, >= userFirstName <! >= WelcomeMessage user:userFirstName <

It is important to note the >, >=, and < tokens in Listings ?? and ??. These tokens, unless immediately preceded by the escape character \, indicate the usage of Artifacts or CMS Variables and are applied as follows: The > and < tokens can only be used with Files (as shown in line ?? of Listing ??), and indicate that the corresponding segment will be replaced with a hyperlink (or similar mechanism) to allow users to access and download the corresponding le; On the other hand, the >= and < tokens which can be used with any kind of Artifact, as depicted in lines ?? and ?? of Listing ?? indicate that the placeholder should be replaced with the contents of the used Artifact. The manner in which those contents should be included is CMS-specic, and depends on the nature of the artifact (e.g., a Binary File with an image should be included as an HTML image tag that points to the image, and not as a Base64-encoded string). If the artifact is a Placeholder String, then it is possible to provide values for the various placeholders (if any) that have been dened in it, as illustrated in line ?? of Listing ??. In the same manner, the contents of Files will also be treated as Placeholder Strings, as long as the CMS can detect that they contain text; this can be done, for example, by scanning the le to check if it contains only valid ASCII characters, or detecting the existence of an UTF BOM (Byte Order Mark) at the start of the le. If a File does not pass that test, then it will be considered as containing binary content and handled in the previously described manner; However, the >= and < tokens do not indicate the usage of Artifacts exclusively, as these tokens can also be used to include the value of a CMS Variable (as shown in line ?? of Listing ??), in the same manner that an Artifacts contents are included in the Content. Furthermore, it is possible to use CMS Variables as input for the placeholders in Artifacts, as illustrated in line ?? (of the same listing). 25

2.1. WEBSITE TEMPLATE It should be mentioned that the semantics for these tokens are inspired by web frameworks that rely on the processing of server-side pages. In such frameworks, a web page is specied by using HTML in which placeholder markups typically called tags are included. Each tag can specify that it either (1) contains code to execute (without returning any output value), or (2) contains an invocation of a method or a variable, and the return value of this execution should be included in the page.

2.1.8

Visual Themes View

The Visual Themes view meant for the Web Designer role determines how each of the web applications structural elements should be viewed by users, in terms of visual elements such as color, width, or line thickness. This is done by dening CSS (Cascading StyleSheet) classes and specic inline styles, in accordance with the best practices of web design. The concepts for this view are depicted in Figure ??.

Figure 2.11: Abstract syntax for the WebSite Templates Visual Themes view. A Visual Theme can be considered as an aggregator for a set of semantically related CSS Classes (described next). This concept denes the following attribute: Name (string): The name of the Visual Theme (e.g., Blue, Ocean Colors). Listing ?? depicts the concrete syntax for the Visual Theme concept. Listing 2.22: Concrete syntax for Visual Theme.
1

Visual Theme Ocean Colors

A CSS Class is a concept that maps to a concrete CSS class, which will be used to adjust the rendering of an HTML element in a web browser or web-enabled device. This concept denes the following attributes: Name (string): The name of the CSS class (e.g., WebPageDefinition); 26

2.1. WEBSITE TEMPLATE Denition (string): The CSS statements that should constitute the underlying CSS class (e.g., width:33%; text-align:left;)5 ; Type (Visual Conguration Type): The kind of Structural element to which instances of this CSS class may be applied. It must assume one of the values of the Visual Configuration Type enumeration: WebSite; WebComponent; Dynamic WebPage Container; or Dynamic WebPage. Listing ?? provides some examples of the concrete syntax for the CSS Class concept, as lines ???? and lines ???? depict the denition of two CSS Classes, Nemo Writing and OceanBlue Component, respectively. Listing 2.23: Concrete syntax for CSS Class.
1 2 3 4 5

Visual Theme Ocean Colors with CSS Class Nemo Writing for WebComponents as fore-color: orange; CSS Class OceanBlue Component for WebComponents as width: 100%; back-color: blue;

On the other hand, a Visual Conguration can be considered as a specication of CSS visual properties for a certain structural element (e.g., a specic WebComponent). It is an association between a structural element and a set of CSS Classes, and it also denes the following attribute: Specic CSS (string): A set of CSS statements that should be used as an inline CSS style in the Structural element to which this Visual Configuration is assigned. Its format is the same as for the CSS Class Definition attribute. Thus, instances of this concept can be viewed by modelers as applying the CSS classes to an element (with some eventual customizations to the element, by using the Visual Configurations Specific CSS property to include style information like background color or strong text that makes sense in that element but not in the CSS Class itself). Listing ?? provides some examples of the syntax for the Visual Themes view: Lines ???? illustrates a Visual Configuration that also contains some Specific CSS (with value width:33%; fore-color:navy;); and Line ?? also illustrates a Visual Configuration, now taking place between a set of CSS Classes and a WebComponent, in such a way that OceanBlue Component is
5

Modelers are advised to consult the W3Cs documentation regarding CSS.

27

2.1. WEBSITE TEMPLATE applied before Nemo Writing (of course, it is possible to provide specic CSS by using the same syntax as in line ??). It should be noted that these examples do not contain the Definition of the CSS Classes OceanBlue Component and Nemo Writing, as they are assumed to be already provided in Listing ?? (namely in lines ?? and ??, respectively). Listing 2.24: Concrete syntax for Visual Conguration.
1 2 3 4 5

Visual Theme Ocean Colors with CSS Class OceanBlue Component is applied to WebComponent My Blog with inline width: 33%; fore-color: navy; CSS Class (OceanBlue Component, Nemo Writing) is applied to WebComponent My Blog

Additionally, a Visual Theme can reference a set of Files, which will be used to support the web applications visual presentation. Such support Files are likely to be images and videos, although they can also be CSS les, Javascript les (e.g., to enable showing elements with rounded corners in older web browsers), or any other les that the Web Designer considers relevant for the web applications visual. Listing ?? provides an example of the usage of a File as support for the Visual Theme (in this case, it consists of an image with a companys logo, as indicated by the Files name). Listing 2.25: Concrete syntax for a Visual Theme referencing Files.
1 2 3

Visual Theme Ocean Colors with (. . . ) Supported by le my company logo.jpg

Finally, as was previously mentioned, a Visual Configuration association can only take place between CSS Classes and specic Structure view elements: Container-typed CSS Classes (i.e., with the Type attribute assuming the value Container) and Containers; Dynamic WebPage-typed CSS Classes and Dynamic WebPages; WebComponent-typed CSS Classes and WebComponents; WebSite-typed CSS Classes and the modeled WebSite itself. Thus, non-matching elements (e.g., a WebComponent and a CSS Class with Type assuming the value Dynamic WebPage) cannot be associated by a Visual Configuration element. Although at rst this may seem like a senseless restriction (especially to someone with a background in web design, in which the same CSS class is often applied to various types of HTML elements), the rationale for this choice is to strong-type CSS classes, in order to 28

2.2. TOOLKIT avoid some typical errors (e.g., a CSS class trying to set a property value for an HTML element that doesnt contain that property). Although most web browsers do not alert the user about errors when this kind of mismatch problem occurs (the browser typically just logs the issue and ignores the style assignment), it is a bad practice nonetheless, because dierent web browsers may interpret the style assignment in dierent manners, which in turn will often lead to unexpected results.

2.2

Toolkit

Although CMS-IL provides the WebSite Template elements (presented in the previous section) out-of-the-box, the language also allows for its extension to a certain degree by means of Toolkits. A Toolkit can be regarded as a behavior-oriented complement to Template elements, as it enables the addition of new Template-related concepts (namely Roles and WebComponents) that are particularly oriented toward supporting the specication of a web applications behavior. Like a WebSite Template, a Toolkit is dened according to a set of views (illustrated in Figure ??), namely: The Roles view, which denes the user roles that will have the responsibility of performing actions in the context of the Toolkits WebComponents; The Code view, which denes source code (of either CMS-IL or a CMS-specic programming language) that can be used by other views; The Events view, in which it is possible to specify additional commands that will be performed whenever specic CMS-related events occur; The Variability view, which species the variability points that will congure the Toolkits operation; The Domain view, dening the Toolkits domain model and its data structure; and The WebComponents view, specifying new kinds of WebComponent (namely their internal elements, and the commands to run when those elements are used). These views are explained in the following subsections.

2.2.1

Roles View

The Toolkits Roles view is dened by two concepts, Role and Role Specialization. The former is used to specify the expected kinds of participation (and responsibilities) that will take place in the context of the additional functionality provided by the Toolkit,

29

2.2. TOOLKIT

Figure 2.12: The views involved in the denition of a Toolkit. while the latter is used to determine the specialization relationships between those kinds of participation. Figure ?? depicts the concepts for the Roles view.

Figure 2.13: Abstract syntax for the Toolkits Roles view. Furthermore, any instance of a Toolkit Role is automatically considered a specialization of the WebSite Template Role concept. Thus, when dening a WebSite Template, each modeled Role is always an instance of the WebSite Templates Role concept, but it may actually be an instance of a Toolkit Role. Role models those expected responsibilities, and denes only the following attribute: Name (string): The Roles name. There must not be two Toolkit Roles (within the same Toolkit) with the same name. 30

2.2. TOOLKIT Listing ?? illustrates the concrete syntax for the Role concept. As this example shows, a Toolkit Role is represented in the same manner as a WebSite Templates Role, although it should be noted that these two concepts will be contained within dierent contexts (a Toolkit and a WebSite Template, respectively), which removes the possibility of erroneously using one concept instead of the other. Listing 2.26: Concrete syntax for Toolkit Role.
1

Role Document Manager

It is important to note that Toolkit Roles are not modeled in the same manner as the WebSite Templates Roles, as these two concepts are located in dierent conceptual levels. In fact, the only relationship between the Template Role and Toolkit Role concepts is that each modeled Toolkit Role will actually be a specialization of the Template Role concept (which, in turn, will be modeled as a concrete Role in the WebSite Template). Thus, when modeling the WebSite Template Roles view, each Role will be an instance of the WebSite Templates Role concept presented in Subsection ??, but it may also be6 a Toolkit Role. However, because the Toolkit is modeled in a dierent conceptual level than the WebSite Template, it is not possible to use Toolkit Roles and WebSite Template Roles in the same model, nor is it possible to model Role Delegations in the Toolkit Roles view. The reason for providing such a simple view is that the Role concept is used solely to indicate the existence of a kind of participation that the Toolkit will be expecting when someone uses its functionality. The actual specication of what the Role can do will be addressed afterward in the Toolkits remaining views. On the other hand, Role Specialization models specialization relationships between Roles, as the name indicates. In other words, it is possible to specify that a Role A is a particular case of a Role B, and so the former can ll in the shoes of the latter (although the reverse is not true). Note that this is not the same as delegating responsibilities (which is the purpose of Role Delegation): a specialization is typically meant as a permanent relationship between Roles, while a delegation often expresses a temporary relationship. Listing ?? illustrates a Role Specialization relationship that takes place between two Roles, Document Manager (the specialization) and Document Operator (the generalization).

One of the most important issues to be aware of when dealing with metamodeling is the ambiguity of the is-a term, as it can refer to either specializations or instantiations. Each of these possibilities carries a completely dierent set of semantics with it.

31

2.2. TOOLKIT Listing 2.27: Concrete syntax for Role Specialization.

Role Document Manager specializes Role Document Operator

2.2.2

Code View

The Code view is what eectively gives CMS-IL its programming language characteristics that are familiar to most web application developers. It can be considered as a set of function declarations in conjunction with a subset of the Ruby programming languages abstract syntax, which in turn makes this view (arguably) the most complex one in CMS-IL. Figure ?? presents a simplied representation of the concepts for this view (the Statement concept is not further developed because of the similarity with Ruby).

Figure 2.14: Abstract syntax for the Toolkits Code view. Although the Code view is presented separately from the other Toolkit views, it is nevertheless the cornerstone for most of those views, as it is possible for elements in them (e.g., Methods in the Domain view) to reference or contain elements from the Code view. This view provides some concepts, of which the most relevant are Function and Lambda. These concepts can also typically be found in some form in other programming languages (imperative or otherwise), such as C, Java, or Python. This view starts by dening a set of Data Types, which are possible kinds of values (to be used in the denition of other elements). Each Data Type value is either: (1) a reference to a CMS element (e.g., a specic user), in the case of CMS Data Types; or (2) a value that is copied when it is used (e.g., in a Statement), in the case of Primitive 32

2.2. TOOLKIT Data Types. This follows the same data categorization strategy as Java or C#, which typically divide data types in two main categories reference types and value types that determine whether an instance has referential identity or not: reference types have referential identity, while value types do not. CMS-IL denes two main kinds of Data Type: Primitive Data Types and CMS Data Types. A Primitive Data Type is a kind of element that is usually provided by any software system (e.g., strings, integers, dates). On the other hand, a CMS Data Type is used to represent the identication criteria for a concrete instance of a CMS concept; as an example, the User data type can be used to store whatever information is necessary to uniquely identify a concrete user in the CMS system. An easy way to distinguish between these two kinds of Data Types is that the names of CMS Data Type values always start with an uppercase character (e.g., User), while the names of Primitive Data Type values always start with a lowercase character (e.g., string). CMS-IL denes the following (basic) Primitive Data Types (note the lowercase initials): string integer decimal boolean time date

Furthermore, the following CMS Data Types (with uppercase initials) are also made available by CMS-IL: User Role Dynamic WebPage WebComponent Language Visual Theme CSS Class Content Artifact

However, CMS-IL also provides the following Data Types: The enumeration, which is a Primitive Data Type that allows the Toolkit Developer to specify a set of allowed names (which, in turn, represent specic values) for that Data Type; 33

2.2. TOOLKIT The Tuple, which enables the denition of n-tuples (i.e., ordered sequences of n elements, each of which can be of any Data Type, including other Tuples); and The Array, which is equivalent to arrays in other programming languages, and allows the storage of several values of a certain Data Type. The Toolkit Developer is also allowed to create new Data Types (other than Tuples and Arrays) by specifying Entities and Associations in the Domain view (see Subsection ??). The reason why the Code views enumeration is not used here is that a Custom Option can only be a name, while it is possible for an enumeration to assume other kinds of values (further details are available in this guide TODO). The cornerstone of the Code view is the concept of Lambda, which is derived from lambda calculus and is a fundamental concept in many functional programming languages, such as Lisp or Scheme. From a mathematical perspective, a lambda function consists of simply of an anonymous function, such as (x, y) x x + y y or x x (which correspond to the anonymous forms for the square sum and identity functions, respectively). Similarly, a CMS-IL Lambda consists of a function not to be confused with the Function concept, which is presented further down this text that (1) is anonymous (i.e., it has no name), (2) receives a (possibly empty) set of Parameters, (3) performs some instructions, and (4) returns a corresponding value. A Parameter is a concept equivalent to UMLs Parameter or to the concept of parameter in OOP. A Parameter has only a Name and an optional Type: the latter, if specied, is only used by the CMS system as a precondition to automatically ensure that a runtime value of the expected Type is assigned to the Parameter (e.g., if a Lambda expects a Parameter of Type integer, then it would be incorrect to provide a string when invoking that Lambda). A specic Lambdas set of expected Parameters is called its signature (which is why Lambda inherits from the abstract class Signature Element), and is used to check whether a certain Lambda can be used in the context of other elements that can contain Lambdas. This check is made by ensuring that there is no signature conict between the Lambda and its container element, namely that: (1) their signatures have the same number of Parameters; and (2) their Parameters Types, if declared, do not conict (e.g., a Lambda that receives a single Parameter of type Role should be used with an element whose signature declares a single Parameter of type User). A Lambda, being a function, also returns a value. This value can be one of the following: (1) one of the aforementioned Data Types, or even a Tuple composed of other Data Types; or (2) the special value nil. Although languages such as C# treat lambdas as 34

2.2. TOOLKIT anonymous pieces of code that may (or may not) return a value, CMS-IL Lambdas always return a value, even if that value is nil; this is similar to Pythons functions, which always return a value (when no value is returned by the developer, the function returns the special value None). It should be noted that, like in Python, Lambdas can take advantage of the Tuple Data Type to (1) return multiple values of dierent types, and (2) receive structures of related values (e.g., like those that can be dened with Cs struct) without requiring the denition of multiple Parameters (one for each value). Another fundamental concept in this view is the Function. Considering the previous denition of the Lambda concept, it suces to say that dening a Function consists simply of assigning a name to a Lambda. The reason why this concept is particularly important is that CMS-IL does not support the denition of Lambdas on their own (i.e., without being within the context of another element that will contain the Lambda). Thus, the only way to dene a Lambda that can be used in multiple locations of the CMS-IL model (which, in turn, enables code reuse) is to dene a Function, which can then be used in most situations that expect a Lambda (it is also possible to dene an alias for a Lambda, which in practice is the same as creating a Function; aliases are further described in Subsection ??). A Function can contain any kind of Lambda provided by CMS-IL. Unlike other programming languages, CMS-IL provides two dierent kinds of Lambda: the Pure Lambda and the Platform Lambda. A Pure Lambda consists of platform-independent source code that can operate not only over instances of the various elements dened in other Toolkit views, but also over the CMS system itself. A Pure Lambda is composed of a set of Statements, which are instructions to be run by the CMS system. CMS-IL supports a simplied subset of the statements dened by the Ruby programming language, as CMS-IL does not support the denition of classes7 : creating data structures is handled by the Domain view (explained in Subsection ??) and Tuples. However, CMS-IL also adds a small set of predened classes, namely: (1) classes such as Role or User, for manipulating instances of the Toolkits elements; and (2) the class CMS, for interacting with the CMS system itself. Of course, it will be the CMS systems responsibility to dynamically convert these CMS-IL Statements into code that can be run on its environment; an example would be the conversion of a Statement <body> unless <condition> into a set of PHP statements, when running on a CMS system such as Drupal or Joomla. On the other hand, a Platform Lambda can be considered to be a platform-specic Lambda, and contains a set of Environment Snippets. An Environment Snippet is a
7

Further details of the various kinds of Statement available are provided in this document TODO.

35

2.2. TOOLKIT platform-specic source code segment (e.g., a string with some Java statements) that is meant to be executed directly by the CMS system in which the model is deployed, and consists merely of a pair <target environment, code to run>. An Environment Snippet can also specify an Environment Check, which consists of a condition (or set of conditions, organized in a logical boolean manner) that must be satised in order to run that Snippet (e.g., by ensuring that the current environment consists of Drupal 7 and Java 6 or higher). Because a Platform Lambda contains multiple Environment Snippets (each for a dierent language and/or environment), it is possible for a Toolkit Developer to provide multiple native implementations of the same desired behavior (e.g., an equivalent set of instructions in Java and in PHP), and the CMS system can choose at runtime which of the implementations to run, according to its own environment, and the Environment Checks (if any) that each implementation assumes. The denition of multiple implementations, in turn, can mitigate the Platform Lambdas platform-specicity. Furthermore, if the Toolkit Developer intends to deploy the Toolkit onto a specic CMS, then using that CMSs API in the CMS-IL model becomes a trivial matter, thus eectively addressing the issue of integrating a model with a system that already exists. Finally, CMS-IL also provides a Ruby-based error-handling mechanism. This is embodied by the Error concept, which can be considered as equivalent to Rubys exceptions, and consists of: (1) a Name, which allows a certain error to be identied and handled separately from other errors; and (2) being a Signature Element, it also contains a set of Parameters that serve as arguments for the error (e.g., the environment variables that led to the errors occurrence). Furthermore, an Error can also be a specialization of another Error (its parent), in which case it can be considered as a particular case of that parent Error, and inherits all of the parents Parameters. Errors are raised in CMS-IL by means of the raise keyword (which is also present in Ruby), which can be invoked by raising: (1) a previously declared Error, in which case the Error can (and should) receive its Parameters; or (2) a new Error, previously undeclared, in which case it is not possible to provide any Parameters to the Error. Likewise, Errors can be handled in CMS-IL source code by using begin/rescue code blocks (in the same manner as Ruby). The rst topic concerns this views concepts from a mathematical perspective. Inspired by functional languages, the Code view is meant to be viewed as the underpinnings for the denition of mathematical functions, which will be evaluated while the web application is running. Thus, this view denes mostly concepts that are oriented toward this purpose: lambdas, functions, and function arguments (known as Parameters in CMS-IL, UML, and OOP languages). However, CMS-IL itself should not be considered a functional language, because it is more oriented toward the changing of state during the web applications runtime, in the likeness of imperative languages such as C; this mutable state is determined 36

2.2. TOOLKIT primarily by the Entities of the Domain view (described in Subsection ??), which reect the web applications domain model. Another topic is related to the variables used in the CMS-IL Statements that are depicted in Listing ??. These use dynamically typed variables, which means that the type of a variable does not need to be declared, and is only determined at runtime. More specically, CMS-IL supports the usage of duck typing in the denition of Functions and Lambdas. Duck typing consists of a dynamic typing approach in which the possible actions that can be performed over an object (provided as a parameter) are not determined by the objects type, but rather by the functionalities (i.e., properties and methods) that are necessary when using the object. An even better denition (in our own opinion) is the following: Duck typing allows an object to be passed in to a method that expects a certain type even if it doesnt inherit from that type. All it has to do is support the methods and properties of the expected type in use by the method.8 The usage of duck typing in CMS-IL allows Toolkit Developers to specify the web applications behavior (as Functions and Lambdas) while concentrating on the functionalities oered by a certain object, instead of focusing on the objects type. Nevertheless, CMS-IL Toolkit Developers can easily insert some type-verications (used as sanity checks) into Functions and Lambdas, by optionally specifying the Types of their Parameters and/or return value (and thus disable duck typing for that Parameter). This last feature can help mitigate potential problems that could arise from CMS-ILs use of duck typing (e.g., two types may each provide a methods called log, but with completely dierent and unexpected semantics), as well as facilitate the creation of CMS-IL Toolkits by developers that are more familiar with static typing languages (such as Java). The nal topic regards the usage of the Code views elements by other Toolkit views. More specically, other views can only (1) dene Pure Lambdas (instead of the more generic Lambda) and (2) reference Functions. The reason why Platform Lambdas cannot be directly dened in other views is to ensure that those views are kept as platform-independent as possible (and to keep platform-specic details as localized as possible). In turn, this leads to a CMS-IL model that is potentially easier to adapt to a new CMS system, as the platform-specic elements are located only in a limited set of Functions, instead of being scattered throughout the model. It should also be noted that, whenever a Pure Lambda instance is dened in the context of other views, then both its signature (i.e., its ordered set of expected Parameter Types)
8

Phil Haack, How Duck Typing Benets C# Developers, <http://haacked.com/archive/2007/08/ 19/why-duck-typing-matters-to-c-developers.aspx>

37

2.2. TOOLKIT and its Return Type if any must not conict with the those of the element that contains it. The Toolkit concrete syntaxes illustrated in this document often deal with this potential issue in a simple manner, by dening the Pure Lambda at the same time as its container element, which eectively applies the Pure Lambdas signature to the element. However, this caveat also applies when an element references a Function, and possible alternative concrete syntaxes should be aware of this issue regarding signature conicts.

2.2.3

Events View

The Events view is one of the views that eectively addresses the extension of the CMSs functionalities. In particular, this view allows developers to provide source code (namely Pure Lambdas or Functions) to be run whenever a specic event (such as a new users registration, or the beginning of a new request) takes place in the CMS system. Figure ?? illustrates the abstract syntax for the Events view.

Figure 2.15: Abstract syntax for the Toolkits Events view. This view is centered around (1) the occurrence of events and (2) the running of event handlers when they do. It should be noted that this merely consists of applying the Observer design pattern, which is very often used in CMS systems to enable their extension by third-parties. The notion of events that can occur is captured by the Event concept, which represents events that may occur during the CMS systems usage. In particular, this view denes two 38

2.2. TOOLKIT concepts that inherit from Event, CMS Event and Custom Event. Furthermore, because it is a Signature Element, an Event declares a set of expected Parameters which are specic to the event itself that will be provided to any event handler that addresses it (e.g., the Role.Created CMS Event provides the newly created Role as its Parameter, so that the corresponding event handlers can perform their own work). The CMS Event concept is used to represent generic CMS events that typically occur while the CMS system is used (such as a users successful login). There are several kinds of CMS Event, resulting from our analysis of CMS systems and the lifecycle events that they typically allow developers to hook into. TODO: make exhaustive list of CMS Events On the other hand, a Custom Event enables the declaration of new kinds of Toolkit-specic events. This concept denes the following attribute: Name (string): An identication the event. Listing ?? provides some examples of the concrete syntax for the Custom Event concept: Line ?? depicts a declaration of a Custom Event, Timer Elapsed, that provides no Parameters; and Lines ???? dene another Custom Event, called Magic Has Happened, that provides two Parameters (magicTrick with no specied Type, and magician of Type User). Listing 2.28: Concrete syntax for Custom Event.
1 2 3 4

Event Timer Elapsed can occur Event Magic Has Happened can occur with (magicTrick, User magician)

On the other hand, the notion of event handler is captured by the Event Handler concept (sometimes just called Handler, for simplicity), which determines the code that will be run when the corresponding Event occurs. Each Event Handler either (1) references an already existing Function (see Subsection ??) or (2) provides a Pure Lambda that contains the code to run. Furthermore, the signature of the Event Handlers Function or Pure Lambda must not conict with its Events signature, and the value that is returned, if any, is discarded. Listing ?? provides some examples of the concrete syntax for Event Handlers: Lines ???? illustrate an Event Handler, with a Pure Lambda (dened in lines ?? ??), for the Magic Has Happened Custom Event. This Pure Lambda receives two 39

2.2. TOOLKIT Parameters, trick and performer, which have no declared Types (and thus this Pure Lambdas signature not conict with the signature for the Magic Has Happened Custom Event), and simply calls a Function log that is provided by the CMS class; and Lines ???? illustrate another Event Handler, this one referencing a Function: lines ???? declare a simple Function Tell Magic Trick Occurred, while line ?? declares that the Tell Magic Trick Occurred Function is a Handler for the Magic Has Happened event. Listing 2.29: Concrete syntax for Event Handler.
1 2 3

4 5 6 7 8 9 10 11

When event Magic Has Happened occurs do lambda (trick, performer) = {{ CMS.log A magic trick occurred! It was #{trick} and was performed by #{performer}!, trick:trick, performer:performer }} Function Tell Magic Trick Occurred receives (theTrick, User whoPerformedTheTrick) performs {{ CMS.tellUser Wow! A magic trick! }} When event Magic Has Happened occurs call Tell Magic Trick Occurred

It should be mentioned that these two alternatives (the usage of either a Function or a Pure Lambda) are meant only to facilitate the denition of Event Handlers. Once again, it is important to remember that a Function is only used to name a Lambda. This leads to a Toolkit Developer being able to either use an existing Function (which promotes code reuse), or dene a new Pure Lambda, which is meant to be used only in the context of that Handler.

2.2.4

Variability View

The Variability view allows the Toolkit Developer to dene specic variability points, which will assume the form of conguration options for the Toolkit, when it is deployed on a CMS system. In turn, it will be up to the CMS system to endow the user with an interface that supports this conguration, according to the options specied in this view. Figure ?? illustrates this views abstract syntax. This view is fairly simple, as it provides one important concept, Variability Point (sometimes called just Point, for text brevity), which represents a conguration option that will condition the Toolkits operation. This concept denes the following attributes: Name (string): The name of the Variability Point; 40

2.2. TOOLKIT

Figure 2.16: Abstract syntax for the Toolkits Variability view. Default Value (string): A string that indicates the value this Point should assume if no one explicitly sets its value. This attribute is optional and can be left unspecied, but if it is specied then it must be processable by the target CMS system; Type (Variability Point Type): The kind of value that this Variability Point should assume. In other words, the kind of slot that the CMS system should reserve for this conguration point. Setting a Variability Points Type to a certain Variability Point Type value is very similar to using the Data Type element (dened in the Code view, see Subsection ??). However, a Variability Point has an additional option to provide an ordered set of Custom Option values (which are very much like the Code views enumerations, and are identied solely by their Name), and cannot have a Tuple as its Type. The reason why the Code views enumeration is not used here is that a Custom Option can only be a name, while it is possible for an enumeration to assume other kinds of values. It is up to the CMS system to provide a mechanism for the storage of the values of the Variability Points dened in a Toolkit; to do so, most CMS systems will just have to take advantage of the same CMS-specic mechanism that is already used to store conguration options for predened WebComponents. Listing ?? provides some examples of Variability Points concrete syntax: Line ?? presents a Variability Point, designated Role responsible for document management, that references a Role in the CMS system in which the Toolkit is installed; 41

2.2. TOOLKIT Line ?? depicts another boolean Variability Point, which is called Use version control system and has a Default Value of true; Line ?? also illustrates a Variability Point, an integer called Maximum number of documents to keep in Recycle Bin, with a corresponding Event Handler consisting of a Pure Lambda that simply logs the new value; and Line ?? portrays another Variability Point, Permissions policy, that provides a set of Custom Options, which are illustrated in lines ????. Listing 2.30: Concrete syntax for Variability Point.
1 2 3 4 5 6 7 8 9 10

Point Role responsible for document management is Role Point Use version control system is boolean with default value true Point Maximum number of documents to keep in Recycle Bin is integer when set do lambda (newValue) = {{ CMS.log newValue }} Point Permissions policy with Option Optimistic (access is allowed if any Role allows access) Option Pessimistic (access if blocked if any Role denies access)

Furthermore, each Variability Point belongs to a Variability Point Category (also just called Category), which is just a classier for Points. This concept provides only the following attribute: Name (string): The name of the Variability Point Category. Toolkit Developers can organize such Categories in a tree-like structure, which in turn will allow the Toolkits users to congure it in a step-by-step manner, instead of being presented with all available options in a single screen. Each root Category (i.e., a Category that is not contained by any other Categories), in turn, can be specic to a kind of WebComponent (dened in the WebComponents view, see Subsection ??) or global to the Toolkit itself, depending on whether the Category is declared within the context of a WebComponent. Listing ?? provides an example of this views concrete syntax: Line ?? denes a Variability Point Category, Document Management Options, that contains all the other Categories and Variability Points dened in the example; Line ?? presents a Variability Point, designated as Role responsible for document management, that is contained by the aforementioned Category; and Lines ?? and ?? dene two other Categories, Operational Parameters and Access Control, that are sub-categories of Document Management Options (and which are meant to contain other Points and/or Categories). 42

2.2. TOOLKIT Listing 2.31: Concrete syntax for Variability Point Category.
1 2 3 4 5 6 7 8 9 10

Variability Category Document Management Options denes Point Role responsible for document management is Role contains ( Category Operational Parameters denes ( (. . . ) ) Category Access Control denes (. . . ) )

A Variability Point also declares a Custom Event (see Subsection ??) called <Variability Points Name> Changing, in which the Variability Points Name string results from the concatenation of the Points Category Names with the Points Name itself, using : as a separator (e.g., for a Variability Point Maximum Size contained in a Category Recycle Bin, which in turn is contained within another Category Document Management, the name of the corresponding Custom Event would be Document Management:Recycle Bin:Maximum Size Changing). Although it is not required that Toolkit Developers provide an Event Handler for this Custom Event, any such Handlers will be (1) provided with the Variability Points new value in a Parameter, and (2) run before the Points value is changed (thus preventing the Point from being changed if an error is raised by the Handler), which can be useful for purposes such as logging or user-input validation. It is also possible for a Toolkit Developer to provide a Handler at the same time that the Variability Point is declared, which expedites the process of declaring the Point and handling its changes with some validation code. Listing ?? provides an example of this views concrete syntax (based on the previous example in Listing ??): Line ?? illustrates a Variability Point, an integer called Maximum number of documents to keep in Recycle Bin, with a corresponding Event Handler that consists of a Pure Lambda which simply logs the new value (see line ??); and Lines ???? specify that the Function Do Something With Number (dened in lines ?? ??) is an additional Event Handler for the Custom Event that is associated with the Variability Point dened in line ?? (as this example shows, the immediate declaration of a Handler, as done in line ??, is much cleaner).

43

2.2. TOOLKIT Listing 2.32: Concrete syntax for Variability Point Events and Event Handlers.
1 2 3 4 5 6 7 8 9 10 11 12

Variability Category Document Management Options contains ( Category Operational Parameters denes ( Point Maximum number of documents to keep in Recycle Bin is integer when set do lambda (newValue) = {{ CMS.log newValue }} ) ) Function Do Something With Number receives (number) performs {{ (. . . ) }} When event Document Management Options:Operational Parameters:Maximum number of documents to keep in Recycle Bin Changing occurs call Do Something With Number

13

2.2.5

Domain View

The Domain view is where the Toolkits underlying domain model is specied. It is very similar to the UMLs Class Diagram concepts, and consists of specifying the domain Entities that will be manipulated by the Toolkits Event Handlers and WebComponents (described in Subsections ?? and ??, respectively). Figure ?? illustrates the abstract syntax for this view.

Figure 2.17: Abstract syntax for the Toolkits Domain view. The most important concept in the Domain view is the Entity concept. This concept is used to model the entities (e.g., Person, Credit Card, Document) that will be manipulated

44

2.2. TOOLKIT by the users of websites where the Toolkit is used. The Entity concept denes the following attributes: Name (string): The name of the Entity (e.g., Person); Is Abstract (boolean): Whether the Entity is considered as abstract; default value is False. A consequence of marking an Entity as abstract is that it cannot have direct instances: you must dene another Entity that specializes it (by using the Specialization concept, described further down this text), in order to be able to have (indirect) instances of this Entity. Listing ?? presents the concrete syntax for the Entity concept: (1) line ?? depicts an Entity called Person; and (2) line ?? represents an abstract Entity called Animal. Listing 2.33: Concrete syntax for Entity.
1 2 3

Entity Person Abstract Entity Animal

An Attribute is a eld that belongs to an Entity. Whenever an instance of an Entity is created, corresponding instances for its Attributes will also be created, which will be used to store values that constitute the instances state (e.g., if a person has paid its monthly subscription for a magazine). If we consider that an example of Entity could be Person, then typical Attributes for this Entity would be Name, Date of birth, or Address. This concept denes the following attributes: Visibility (Visibility Level): The visibility level of the Attribute (i.e., whether the Attributes value is accessible by other elements). It can assume one of the following Visibility Level values: Private: The Attributes value can only be accessed within the context of the current Entity (i.e., specializations of this Entity will not be able to access this value); Protected: The Attributes value can be accessed within the context of this Entity(i.e., specializations of this Entity are also able to access this value); Public: The Attributes value can be accessed independently of the context. These semantics are very much like in other OOP languages, such as Java, and so we will not elaborate on them in this document; Name (string): The name of the Attribute. It cannot include the dot (.) character; Is Identication Criteria (boolean): Indicates whether the value of this Attribute can be used to uniquely identify the corresponding instance of the Attributes Entity, from a set of other possible Entity instances. Default value is False. 45

2.2. TOOLKIT Furthermore, each Attribute must have a certain Type, which is an indication of the kind of value to be stored and is determined by the Data Type concept (dened in the Code view, see Subsection ??). An Attribute can have its value determined by a Pure Lambda, instead of being used as a slot for holding that value. However, if the Attribute uses a Pure Lambda to determine its value, then: (1) it is not possible to assign values to that Attribute (because no such slot exists); and (2) the Attribute will not be considered as a value to be stored in the CMS database (or other persistence mechanism that is used). Thus, from a practical perspective, dening this kind of Attribute is equivalent to dening a Method that (1) receives no Parameters (and can only access the current instance, via the self keyword) and (2) returns a value that complies to the Attributes Type. There are some notes and constraints regarding the denition of Attributes, namely: There cannot be two Attributes with the same name within the same Entity; It is possible for more than one of the Entitys Attributes to be identication criteria. If this happens, then instances of the Entity can be uniquely identied by considering the values of all its identication criteria Attributes put together; It is also possible for an Entity to not have any Attributes that are identication criteria. In this case, it will be up to the target CMS system (which will actually run the Toolkit) to obtain some other identication criteria for instances of the Entity (typically by adding an object ID (OID) column to a supporting database). Listing ?? presents some examples of the concrete syntax for the Attribute concept. More specically, it declares an Entity with: (1) an Attribute called Name, of type string, in line ??; (2) an Attribute called Date of birth, of type date, in line ??; (3) an Attribute called ID Number, of type integer, in line ??; (4) an Attribute called CMS User, of type User, in line ??; (5) an Attribute called Contacts, of type Array of strings and multiplicity between 1 (lower-bound) and innity (upper-bound), in line ??; and (6) a derived Attribute Age, in lines ????, that uses a simple calculation to determine the persons age. It should be noted that, although the Pure Lambda depicted in lines ???? of Listing ?? uses dynamically typed variables (i.e., it uses a variable, called result, whose type is only checked at runtime), the Attributes dened in lines ???? can be considered as statically typed (because their types are declared and checked at design time). The reason why Attributes are statically typed is because, when the CMS-IL model is deployed, they will be also used by the CMS system to dene the database schema with which to store their values. If a dynamic typing mechanism was to be used when declaring Attributes, this would require that the CMS system either (1) do a simulated run of the model, in 46

2.2. TOOLKIT Listing 2.34: Concrete syntax for Attribute.

Entity Person has Attribute Name as identication string birthDate = Attribute Date of birth as date Attribute ID Number as integer Attribute CMS User as User contacts = Attribute Contacts as string[1..] Attribute Age as integer given by {{ result = date.today - self.birthDate result = result.inYears return result }}

order to discover the type of the rst value that is assigned to the Attribute (and risk further problems if another value, of a dierent type, was assigned later on to that same Attribute), or (2) use a storage mechanism that stores not only the value but also its type (such as SQLite9 ; both of these options pose considerable problems and constraints, which is why the static typing mechanism is used when declaring Attributes. The Domain view also provides the concept of Method, which is equivalent to UMLs Operation or OOPs concept of methods. This concept denes the following attributes: Name (string): The name of the Method. It cannot include the dot (.) character; Return Type (Data Type): Establishes a constraint over the kind of values that can be returned by this Method. This is optional; if no Return Type is specied, the Method can return a value of any kind. An Entity can hold a set of Methods, which are always invoked in the context of a specic instance of that Entity. A Method may contain a Pure Lambda (which is platform-independent, as described in Subsection ??): if it does not contain a Pure Lambda, then the Method is considered to be abstract (i.e., it is not implemented), and it must be implemented in any non-abstract Entities that specialize the Entity containing this abstract Method (just like in typical OOP languages). Because it is a Signature Element, a Method can also receive an ordered set of Parameters, and its Pure Lambda (if any) can access not only the Methods Parameters, but also the Entity instance for which it was invoked, with the self keyword. Listing ?? presents an example of the concrete syntax for a Method, as lines ???? dene a Method, getFirstContact, that (1) receives no Parameters, (2) returns a string, and (3) performs a simple indexing operation. It should be noted that the abstract syntax and the concrete syntax for a Method are almost the same as for a Function (see Subsection ??). The reason for this similarity is
9

http://www.sqlite.org

47

2.2. TOOLKIT Listing 2.35: Concrete syntax for Method.

Entity Person has Method getFirstContact returns string performs {{ result = self.contacts.atIndex 0 return result }}

that these two concepts are almost equivalent, the only dierences between them being that: (1) a Function is not attached to any element (i.e., it just exists, and can be invoked from any point in the Toolkit), while a Method is part of an Entity, and can only be invoked in the context of an instance of that Entity; and (2) a Functions Body must be specied, and can be any kind of Lambda (including a Platform Lambda), while a Methods implementation if any must be a Pure Lambda (which, by nature, is platform-independent and easier to specify and validate). An Entity can itself contain two Pure Lambdas that will act as the Entitys constructor and destructor (both are optional, and will be invoked after an instance is created and before an instance is destroyed, respectively). Unlike programming languages like Java or C#, CMS-IL only supports the denition of a parameterless constructor in any Entity. This is because such constructors are responsible only for initializing the new instance accessed via the self keyword with default values (which is why Attribute does not provide a default value property), or other initialization operations (such as logging or inserting the instance into a registry). Listing ?? depicts the concrete syntax for these Entity-contained Lambdas: (1) line ?? depicts the syntax for representing an Entitys constructor; and (2) line ?? provides the syntax for an Entitys destructor. Listing 2.36: Concrete syntax for Entity constructor and destructor.
1 2 3 4

Entity Person when created does {{ (. . . ) }} when destroyed does {{ (. . . ) }} has (. . . )

The Association concept enables, as the name suggests, the modeling of associations between Entities. CMS-IL only supports binary associations (i.e., associations between two Entities), although the two Entities can be the same, enabling reexive associations. This concept only denes the following attribute: Name (string): The name of the Association (e.g., Owns).

48

2.2. TOOLKIT Just as important as the Association concept is the Association Role concept. An Association contains exactly two Association Roles (one for each of the associated Entities). An Association Role is what actually links each Entity to the Association, and determines the part that the linked Entity will play in the Association or, from each entity E1 s perspective, the role of entity E2 in relation to itself. This concept is linked to an Entity (typically called its related Entity), and denes the following attributes: Name (string): The name of the Association Role. It is mandatory, and it cannot include the dot (.) character; Multiplicity - Lower Bound (integer): The minimum number of instances of related Entity that this Association Role must reference10 . If there should be no lower bound, then the asterisk character (*) should be used; Multiplicity - Upper Bound (unlimited natural): The maximum number of instances (of related Entity) that this Association Role must reference. If there should be no upper bound (i.e., the Association Role can reference an innite number of instances), the asterisk character should be used; Contains Other Entity (boolean): Whether the Association carries the semantics of composition. More precisely, this determines whether the Association Roles related Entity is composed of the other Association Roles related Entity. A consequence of this being True is that, when an instance of this Association Roles related Entity is discarded, then the referenced instances in the other Association Role will also be discarded. Default value is False. It is an error for the two Association Roles within the same Association to have their Contains Other Entity attribute with the value True (because it would be impossible for an Entity to contain an Entity that contains it). Listing ?? presents some examples of the concrete syntax for Associations, namely: Line ?? denes a typical Association between Person and Credit Card; Line ?? also denes an Association (but now with containment semantics) between Folder and Document. Listing 2.37: Concrete syntax for Association.
1 2 3

Entity Person (as 1 Owner) is associated with Entity Credit Card (as Card) as Owns Entity Folder (as Container) contains Entity Document (as Content) as Holds

10

Be aware that, like in other modeling languages such as UML, each modeled concept is actually a representation of a set of instances. Thus, it is necessary to always be aware that multiplicities are related to the quantity of instances, and not of the concepts themselves.

49

2.2. TOOLKIT To avoid ambiguity in the traversal of the Toolkits Domain model, any Entity must not have more than one opposite Association Role (i.e., an Association Role that is located on the opposite side of the Association to which the Entity is connected) with the same name. Listing ?? provides an example of a Domain model that is invalid because of its Associations: in lines ????, Folder is associated with Document and Shortcut by two Associations, and the two Association Roles that are opposite to Folder have the same name, contents. These two associations make the Domain model invalid, and a way to solve this problem is to assign dierent names to the Association Roles related to Document and Shortcut (see lines ????). Listing 2.38: Example of valid and invalid Association.
1 2 3 4 5

Entity Folder (as 1 container) is associated with Entity Document (as contents) as Holds Entity Folder (as 1 container) is associated with Entity Shortcut (as contents) as Holds Entity Folder (as container) contains Entity Document (as documents) as Holds Entity Folder (as container) contains Entity Shortcut (as shortcuts) as Holds

This constraint makes sense when the designer looks at Folder in lines ????, and looks at its related Associations: the set of Documents of a Folder are known to the Folder as its documents, while the set of Shortcuts are its shortcuts. On the other hand, in lines ?? ??, both Documents and Shortcuts would be known to the Folder as its contents, making the model ambiguous. Finally, the Specialization concept allows Toolkit Designers to specify inheritance (generalization or specialization, depending on the point of view) between two Entities, the base and the inheritor. The specication of an inheritance hierarchy between these two Entities allows: The inheritor Entity to be considered as a particular case (or specialization) of the base Entity; The Attributes of the base Entity to also be available to the inheritor Entity. It is not possible for Entities to use multiple inheritance (i.e., for an inheritor Entity to have more than one base Entity), in order to avoid possible conicts coming from Attributes or Association Roles with the same name in dierent base Entities. Listing ?? depicts the concrete syntax for the Specialization concept. More specically, it establishes a Specialization relationship between Person and Animal. Listing 2.39: Concrete syntax for Specialization.
1

Entity Person inherits from Entity Animal

50

2.2. TOOLKIT

2.2.6

WebComponents View

The WebComponents view allows the Toolkit Developer to specify new kinds of WebComponent that can be used afterward in WebSite Templates. This view is where the functionalities of the CMS are extended, along with the Events view (described in Subsection ??). It is centered around the denition of WebComponents and Support WebPages; however, this view also includes the denition of Web Event Handlers, which are a specialization of the Event Handler concept dened in the Events view. Figure ?? illustrates a simplied representation of the abstract syntax for this view (a more detailed specication is available in the guide TODO). Toolkit Developers act on this view by dening WebComponents, as well as Support WebPages for those WebComponents. As Figure ?? shows, the Toolkits WebComponent concept is particularly important, because its instances are automatically considered specializations of the WebSite Template Modelings WebComponent; in turn, this specialization allows Template Developers to create WebSite Templates in which those new kinds of WebComponent are used, instead of being limited to the generic kinds provided out-of-the-box by CMS-IL. In the WebSite Templates Structure view (see Subsection ??), a WebComponent was considered a basic unit of functionality that the Template Developer would place in Dynamic WebPages. However, in this view, a WebComponent consists of a user interface that will (1) interact with the user, (2) manipulate the web applications domain model (dened in the Domain view, see Subsection ??), and (3) issue instructions to be performed by the CMS. These interactions will be performed in a manner that helps the user to fulll a set of tasks (which are not identied in CMS-IL, as developers are typically not responsible for dening business-oriented tasks, but rather for implementing the functionality that supports those tasks). Furthermore, instances of the WebComponents dened by the Toolkit Developer will be the aforementioned units of functionality that will be placed by Template Developers. A Support WebPage is also a user interface that will perform some work. However, it is dierent from a WebComponent, in that: (1) it consists of a web page (i.e., a node, with a URL, to which a web browser can navigate); and (2) it supports a WebComponent, namely by addressing some operations of the WebComponents tasks. A typical example of a Support WebPage in a Document Management System (DMS) web application would be a web page to edit a documents metadata. Each WebComponent and Support WebPage is a WebInteractionSpace, which can be regarded as a canvas that will display information to the user, and with which the

51

2.2. TOOLKIT

Figure 2.18: Abstract syntax for the Toolkits WebComponents view.

52

2.2. TOOLKIT user will interact. This canvas, in turn, endows WebComponent and Support WebPage with some noteworthy features, namely: (1) it can be accessed by a limited set of Roles (if none are specied, then it is freely accessible by anyone); (2) it can receive a set of Entities, to which it assigns names that identify them within the WebInteractionSpace; and (3) it contains a set of WebElements, which are placed on specic positions of the WebInteractionSpace. The rst feature is used to ensure that only specic Roles can access potentially sensitive pages. It is nothing more than syntactic sugar for specifying an Event Handler that runs when the WebInteractionSpace is initialized, and ensures that the current users set of roles include any of the Roles expected by the WebInteractionSpace. This is why we will not explore this feature further in this document. The second feature is addressed by the Expected Entity concept, which is used to provide arguments to the WebInteractionSpace, in order to specify over which parts of the domain model it will operate. If a WebInteractionSpace is to manipulate (i.e., access and/or change) a certain instance IX of a domain Entity X, then IX must be accessible by one of the following ways: (1) IX is itself provided by an Expected Entity; or (2) IX is accessible by traversing one or more Associations from an instance IY of another Entity Y , IY being provided by an Expected Entity. From a practical perspective, Expected Entities are typically implemented as HTTP request parameters (either GET query string parameters or POST form values).

The last feature is what eectively addresses the user interaction aspect of the WebInteractionSpace. More specically, this aspect is performed by the WebElements that are contained within the WebInteractionSpace. A WebElement consists of an element that will be rendered in HTML (so that it can be displayed in a web browser) and with which the user may be able to interact (e.g., entering some values in a set of form elds, and clicking on a button to submit those values to the web application). A WebElement consists of: (1) an optional Name that identies the element; (2) an optional Width and Height, which respectively specify the desired width and height for the WebElement; (3) an ordered set of CSS class names (not to be confused with the CSS Class concept dened in the WebSite Templates Visual Themes view) that should be considered as being applied to instances of the WebElement (so that its visual aspect can be congured afterward in WebSite Templates); (4) a property Visible, which can be changed at runtime and determines whether any user that can view the WebElements parent element can also view the WebElement itself; and (5) a property Enabled, which is similar to Visible, but instead determines whether users can interact with the WebElement. From a practical perspective, a WebElement can

53

2.2. TOOLKIT be considered as the CMS-IL equivalent to a control in the Microsoft ASP.NET or in Java Server Pages frameworks. CMS-IL denes a variety of WebElement types, namely (1) HTML WebElement, (2) Simple WebElement, and (3) WebElement Container. An HTML WebElement consists of a simple piece of HTML that will be included when its parent (a WebInteractionSpace or WebElement Container) is rendered in a web browser; due to its nature, it is not possible for users to interact with this WebElement (unless the HTML string itself denes browser elements with which the user can interact). On the other hand, a Simple WebElement is the basic element of user interaction that can be placed on a WebInteractionSpace. There are various kinds of Simple WebElement dened by CMS-IL, namely (1) Button, (2) Link, (3) Image, (4) Text, (5) Text Input Box, (6) ListBox, and (7) Selection Box. However, CMS-IL denes a concept for each of these types (these are not represented in Figure ?? for simplicity); this is because each of these concepts will have its own behavior and will provide a specic set of events, in addition to the events that are common to all Simple WebElements (e.g., an Image WebElement should not provide the same events as a Text Input Box WebElement, because they have completely dierent natures and purposes). Furthermore, a WebElement Container (also called just container in this text, for brevity) is a WebElement that is meant to contain other WebElements. CMS-IL denes a variety of WebElement Container kinds: (1) Normal, (2) Popup, (3) Virtual, (4) Horizontal Layout, and (5) Vertical Layout concepts (but CMSMLs List and Table are not present, and the Binding container is ultimately replaced by the Virtual container). The Horizontal and Vertical Layout containers, which are not present in CMSML, can also be used to replace the Binding container, but their main purpose is to assist the Toolkit Developer in establishing a basic visual layout (either horizontal or vertical, respectively) for the containers WebElements. The reason for CMS-IL oering less WebElement Container concepts than CMSML is that the List and Table containers are used only to (1) determine the HTML that wraps its contained WebElements (in selection lists and tables, respectively), and (2) optionally establish a new Binding context. However, web application developers are often used to specifying such HTML by hand, and so they are likely more inclined to dene such tables and lists by (1) using a Normal or Virtual container, (2) including WebElements to represent the information that should be represented, and (3) includ-

54

2.2. TOOLKIT ing some HTML WebElements that contain the intended HTML to wrap the previously mentioned WebElements11 . Each concept that is either a WebElement or a WebInteractionSpace also provides a number of Web Events, which are Events (see Subsection ??) that (1) signal particular occurrences that may take place during the lifetime of the concepts instances, and (2) provide, in the rst Parameter, the instance that triggered the event. Thus, each concepts nature determines: (1) the specic set of Web Events that are provided by that concept (e.g., a Button provides a Web Event which signals that the user has clicked on the corresponding web browser button); and (2) the signature of each of those Web Events. Likewise, WebElements and WebInteractionSpaces can also have a number of Event Handlers for those Web Events that they provide. Finally, the abstract syntax presented in Figure ?? could present a limitation regarding the denition of Event Handlers for WebElements or WebInteractionSpaces, as it would become necessary to dene all of those Event Handlers in the same model in which these elements are specied. In turn, this would mean that other Toolkit Developers would not be able to add their own Event Handlers to these elements (e.g., to send an e-mail when the user clicks on a certain button), unless they could change the original Toolkit. This is why WebElement and WebInteractionSpace dene the Generates Custom Events property: this property species whether its element (1) generates a set of Custom Events that accurately mimics the set of Web Events made available by that element, and (2) automatically invokes those new Events when the corresponding Web Events take place. This eectively establishes a level of indirection that other Toolkit Developers can take advantage of, by providing their own Custom Event Handlers to address those Custom Events. Although this property is False by default (i.e., an element does not automatically generate new Custom Events), it nevertheless allows Toolkit Developers to easily provide specic extensibility points. It should also be mentioned that this feature is syntactic sugar for manually (1) specifying new Custom Events and (2) invoking those Custom Events from the Event Handlers associated with the elements Web Events. Listing ?? presents a simple example of the concrete syntax for this view: Lines ???? illustrate a WebComponent, Manage Documents, that: generates Custom Events (due to the Customizable keyword); invokes the Function Manage Documents Is Displayed when it is displayed to the user; and

11

This would involve an in-depth technical discussion regarding the denition of such HTML structures, which is out of the scope of this dissertation. Further details are available in the guide TODO.

55

2.2. TOOLKIT Listing 2.40: Concrete syntax for the Toolkits WebComponents view.
1 2 3 4 5 6

7 8 9 10

11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Customizable WebComponent Manage Documents as < HorizontalLayout < VirtualContainer < #<ul> VirtualContainer Document List bound to Document.all < #<li> Text Name bound to .Name #</li> > #</ul> > VerticalLayout < Link Create Document to Page Edit Document Button Edit Document on Click do lambda (sender) = {{ document = $Document List$. current ; CMS.goToPage($Edit Document$, document) }} Button Delete Document on Click do lambda (sender) = {{ document = $Document List$.current ; document.delete }} > > > on Initial Display call Manage Documents Is Displayed is supported by WebPage Edit Document expects Entity Document as document as < HorizontalLayout < Text Name: TextInputBox Name Value bound to document.Name > HorizontalLayout < Text Description: TextInputBox Description Value bound to document.Description > HorizontalLayout < Button Cancel on Click do lambda (sender) = {{ CMS.goBackToFrontEnd }} Button Conrm on Click do lambda (sender) = {{ $document$.save ; CMS.goBackToFrontEnd }} > >

contains a set of WebElements some of which with no Name that either: (1) have only layout purposes (the Horizontal Layout and Vertical Layout containers); (2) are used to dene HTML strings (the HTML WebElements that hold the values <ul>, </ul>, <li>, and </li>); (3) are used only as containers for other WebElements (the anonymous Virtual container in line ??); (4) establish a Binding that provides a set of Document Entities (the Document List Virtual container depicted in line ??); or (5) are Simple WebElements that display information (the Text element) or receive user input (the Link and Button elements); Lines ???? depict a Support WebPage, Edit Document, that (1) supports the Manage Documents WebComponent, (2) expects a Document Entity, which it calls document,

56

2.3. WEBSITE ANNOTATIONS and (3) displays and also allows editing of the values of documents Attributes, by using a set of WebElements which are bound to those Attributes. It should be noted that the Expected Entity concept does not automatically ensure that a corresponding Entity instance is received by the WebInteractionSpace. Toolkit Developers can ensure that such an instance is received by checking whether the Expected Entitys variable (e.g., document in line ?? of Listing ??) has the value nil (e.g., by inserting the verication if document == nil). Furthermore, although the example in Listing ?? is similar to the CMSML one presented in Figures ?? and ??, they are not equivalent: the former contains further details concerning the WebElements Bindings and their events, and the latter provides a richer description of the visual layout of those WebElements (in CMS-IL, such visual details are typically relegated to CSS styles, as dictated by web designs best practices).

2.3

WebSite Annotations

As was mentioned, the WebSite Annotations model allows designers to add annotations (representing tags, properties, or general constraints) to a WebSite Template. These annotations can convey any kind of information, such as content conguration options (e.g., a tag Allows Content Subscription applied to a WebComponent can indicate that the WebComponent should provide readers with an RSS feed or similar) or platform-specic deployment data. Unlike Reminders (which are explained in Section ??), these annotations are supposed to be interpreted by the CMS system in which the model is deployed. The most important concept of this model is the Annotation, which denes only the following attribute: Name (string): The Annotations name. This is a string that will be recognized by the target CMS, if any; thus, there are no restrictions to this name, except for characters such as newlines or other restrictions that the target CMS imposes. Figure ?? illustrates the relationship between the various concepts considered by the WebSite Annotations model. Annotation is specialized by various other concepts in this model. The most commonly used is likely the Generic Annotation, which can be associated with any CMS Element (from which all WebSite Template modeling elements inherit, as described later in Section ??). Furthermore, for each WebSite Template modeling element E dened (e.g., WebComponent, Role), CMS-IL also denes an annotation element called E Annotation, which can only 57

2.3. WEBSITE ANNOTATIONS

Figure 2.19: Abstract syntax for the WebSite Annotations model. be associated with instances of E. In other words, a Role Annotation can only be applied to a Template Role, but not to a WebComponent; the only Annotation that can be applied to elements of dierent kinds is a Generic Annotation. Listing ?? depicts some examples of applying Annotations to Template elements: The example on line ?? uses a WebComponent Annotation, called Allows Content Subscription, to annotate the Student Forum WebComponent (the Annotation itself is represented in the form @<Annotation name>, just before the corresponding Template elements declaration); On the other hand, line ?? applies a WebSite Annotation (designated Allows User Registration) to a WebSite; Line ?? applies another WebSite Annotation, Use Caching, to that same WebSite; and Finally, line ?? applies the User Annotation Needs Accessibility Features (suggested in Figure ??) to the User John Doe.

58

2.4. ADDITIONAL ASPECTS Listing 2.41: Concrete syntax for Annotations.

@Allows Content Subscription WebComponent Student Forum of Standard type Forum (. . . ) @Allows User Registration @Use Caching WebSite WebSite (. . . ) @Needs Accessibility Features User John Doe (john.doe@company.com)

Finally, it should be mentioned that the WebSite Annotation model decorates a WebSite Template, allowing designers to specify CMS-specic properties without polluting the Template with platform-specic details. Thus, from a practical perspective, WebSite Template designers do not view two dierent models (the Template and the Annotations), but rather a single model that results from composing those two models (i.e., a model that is the result of extending the Template with the Annotations); this is the perspective that is also conveyed by Listing ??.

2.4

Additional Aspects

Most of the modeling elements of CMS-IL have been presented. However, some topics must still be explained, namely: The handling of functionalities that have not yet been modeled; The denition of aliases for CMS-IL elements; How to import Toolkit(s) into a WebSite Template; How to use imported Toolkit elements in a WebSite Template.

2.4.1

Reminders

CMS-IL provides the concept of Reminders. There are actually two dierent kinds of Reminder: the CMS Reminder and the Toolkit Reminder. Figure ?? illustrates how these Reminder concepts are related to other elements in the language (note that all WebSite Template Modeling and Toolkit Modeling concepts inherit from the CMS Element and Toolkit Element concepts, respectively). A CMS Reminder is used only within WebSite Templates, and indicates a specic element of the model which the WebSite Template Developer must be particularly mindful of (e.g., it can indicate that a certain WebComponent instance must show advertisements 59

2.4. ADDITIONAL ASPECTS

(a) The CMS Reminder concept.

(b) The Toolkit Reminder concept.

Figure 2.20: Abstract syntax for CMS-IL Reminders. according to a specic algorithm). A Toolkit Reminder serves a very similar purpose, but it is only used within Toolkits. These Reminders should not be confused with comments, which are used only to document the model. In fact, both of these Reminder concepts contain not only a Description, but also a property Completed, which ags whether the Reminder has already been addressed (e.g., if a Toolkit WebComponent with the aforementioned algorithm has been dened, and if the Templates WebComponent instance is afterward classied as an instance of that Toolkit WebComponent). With this feature, it is possible for a Template Developer or Toolkit Developer, respectively, to determine whether a model contains any Reminders to be addressed (i.e., changes that must be made to the CMS-IL model). Listing ?? depicts some examples of the concrete syntax for these Reminder concepts: (1) line ?? shows a CMS Reminder that is applied to a Role and has already been addressed (i.e., its Completed property has the value True); and (2) line ?? also shows a CMS Reminder, although this one is applied to a WebComponent and has not been addressed yet. Listing 2.42: Concrete syntax for Reminders.
1 2 3 4 5

!rem>This Role must be assigned to the CMSs most important administrator user.<! Role Big Boss !todo>This must rotate through a predened set of TV channels, on a 5 minute-per-channel basis.<! WebComponent My TV Viewer of Custom type WebTV Receiver

Toolkit Reminders are represented with the same syntax, because: (1) there is no danger of erroneously using one instead of the other (as they are used in dierent metalevels); and (2) this syntax sharing facilitates the learning of the language, as it is not necessary to learn two dierent syntaxes for nearly equivalent concepts.

2.4.2

Aliases

As most examples in this document have shown, CMS-IL elements are uniquely identied by their names, which are surrounded by double quotes (e.g., Morning Type, Timer 60

2.4. ADDITIONAL ASPECTS

However, although this may make a CMS-IL model into something that is near plain English (and thus easier to read by developers not experienced with CMS-IL), developers with more programming experience are likely to nd the constant usage of double quote-surrounded identiers cumbersome and counterproductive, as they increase the number of characters that are required to create a complete and correct CMS-IL model. To address this potential issue, CMS-IL provides the possibility of dening aliases for any instance of a WebSite Template Modeling or Toolkit Modeling concept. An alias consists simply of an identier (a set of alphanumeric characters, with no whitespace between them), and is dened in the same manner as a variable in mainstream programming languages such as C. However, the reason we call these aliases (rather than variables) is that an alias is supposed to do just that: serve as an alternate name for a certain instance, in such a manner that it can then be used anywhere where the corresponding elements name would be used. Listing ?? illustrates some situations in which the aliases can be dened. More specically, an alias can be dened: When the corresponding instance is being declared. Line ?? indicates that the Function Greet and Say Something, which is being declared (the full body for this Function was previously depicted in Listing ??), will also have an alias sayHowdy; As an alternate name for an already existing instance. Line ?? indicates that the Function Greet and Say Something, already declared elsewhere in the model, will have an alias sayHowdy (in practice, line ?? would be equivalent to declaring the Function, and afterward dening the alias for the Function); and As another alternate name for an already existing alias. Line ?? denes an alias sayHello for the previously dened alias sayHowdy. In practice, this is equivalent to writing sayHello = Function "Greet and Say Something" (like in line ??, but with a dierent alias name). Furthermore, sayHello can then be used in any situation where sayHowdy could be used. Listing 2.43: Dening CMS-IL aliases.
1 2 3 4 5

sayHowdy = Function Greet and Say Something (. . . ) sayHowdy = Function Greet and Say Something sayHello = sayHowdy

61

2.4. ADDITIONAL ASPECTS

2.4.3

Importing Toolkits

Toolkits can be used by WebSite Templates, or even by other Toolkits, by using the Toolkit Import concept. This concept consists of a relationship between a Toolkit (the imported Toolkit) and either a WebSite Template or a Toolkit (the importer ). This Toolkit Import concept is actually a set of two such concepts: one at the WebSite Template level (connecting a WebSite to a Toolkit, identied only by name) and the other at the Toolkit level (connecting a Toolkit to another Toolkit, also by name). Figure ?? illustrates how these concepts are related to WebSite Templates and Toolkits.

(a) A WebSite importing a Toolkit.

(b) A Toolkit importing another Toolkit.

Figure 2.21: Abstract syntax for the CMS-IL Toolkit Import mechanism. Listing ?? illustrates the concrete syntax for these two Toolkit Import concepts. More specically, lines ???? depict how a WebSite (in the context of a WebSite Template) imports Toolkits, while line ?? shows a Toolkit importing another Toolkit. Listing 2.44: Concrete syntax for Toolkit Import elements.
1 2 3 4 5

WebSite My Personal WebSite imports Toolkit WebTV Toolkit imports Toolkit Document Management Toolkit Toolkit WebTV Toolkit imports Toolkit Resource Manager Toolkit

It should be noted that the Toolkits are imported by specifying their names. The rationale for this is to (1) solve the metalevel-boundary problem that would arise from a possible relationship between Templates and Toolkit, and (2) potentially reduce the effort of modeling a Toolkit, because imported Toolkits do not need to be dened using CMS-IL. This last reason also enables the usage of elements dened in another Toolkit (e.g., a CMS extension that has been previously developed with a traditional web application development approach), which addresses the issue of integrating the CMS-IL model with existing systems that have been previously installed on the CMS system. Furthermore, the Toolkit Import relationship is transitive. Thus, if a Toolkit T1 imports Toolkits T2 and T3 , and a WebSite Template W ST1 imports T1 , then W ST1 will also automatically import T2 and T3 (without the need for the WebSite Template Designer to explicitly specify that T2 and T3 should be imported by W ST1 ). 62

2.4. ADDITIONAL ASPECTS However, the imports for each Toolkit must be done specically in that Toolkits model; in other words, if we are modeling Toolkit Z which imports Toolkit A, and Toolkit A imports Toolkit B, As import of B must not be represented in Zs model, but rather in As model.

2.4.4

Using Toolkit Elements In Other Toolkits

As was previously mentioned, a Toolkit can import other Toolkits (via the Toolkit Import concept, presented in Subsection ??). CMS-IL only supports the renement of elements in the Roles and Domain views; it is also possible to use (by name) elements from all Toolkit views, thus enabling scenarios such as a Function in Toolkit B creates an instance of a Role dened in Toolkit A. However, aliases dened in a Toolkit cannot be used outside of that Toolkit, even if the Toolkit is imported by a Template or another Toolkit; this limitation is meant to avoid potential errors that could occur if aliases with the same names were dened in dierent Toolkits. The imported elements of T1 can be used just like T2 s own elements (although they cannot be changed ), and imported elements are represented in the same manner as the current Toolkits own elements. There are a few caveats to consider when using these elements: When representing these imported elements, their names must be written in the form <Toolkit name>::<Element name> (to avoid ambiguity in cases where two dierent Toolkits dene some elements with the same name); Imported Domain elements (e.g., Entities) cannot be changed, but they can be rened through Specialization and can participate in Associations. Listing ?? depicts some examples of how to use (or rene) elements dened in another Toolkit. More specically: (1) line ?? illustrates a Role Specialization between two Roles, one of them dened in another Toolkit (WebTV); (2) lines ?? and ?? respectively represent a Specialization and an Association between dierent Entities, some of which are dened in dierent Toolkits; and (3) line ?? indicates that an Event Magic Has Happened, dened in a Toolkit MagicTricks, will also be handled by the Function Send Magic Email (which is dened in the current Toolkit). Note that the :: token is used to separate the names of the Toolkit and the element.

2.4.5

Using Toolkit Elements In WebSite Templates

Finally, the whole purpose of dening a Toolkit is its ultimate inclusion into a WebSite Template, by using the Toolkit Import concept that was presented in Subsection ??. 63

2.4. ADDITIONAL ASPECTS Listing 2.45: Concrete syntax for using or rening elements from another Toolkit.
1 2 3 4

Role Cable Client specializes Role WebTV::TV Viewer Entity Document inherits from Entity Resources::Resource Entity Document (as 1.. Documents) is associated with Entity Entities::Person (as 1 Author) as Author When event MagicTricks::Magic Has Happened occurs call Send Magic Email

5 6

When a Toolkit T1 is imported into a WebSite Template W ST1 , the elements in T1 s following views become available for W ST1 : T1 s Roles view; T1 s WebComponents view. Because Toolkit Roles and WebComponents are also specializations of the WebSite Templates Role and WebComponent concepts, they can be used in nearly the same manner that was presented in Subsections ?? and ?? (respectively). Listing ?? illustrates the concrete syntax for the usage of Toolkit-dened concepts in a WebSite Template: (1) line ?? declares a Role that is an instance of a Role Document Manager, dened in a Toolkit DMS that is imported by the current Template; and (2) line ?? declares a WebComponent that instances the TV Receiver WebComponent in another imported Toolkit, WebTV. Listing 2.46: Concrete syntax for dening WebSite Template elements as instances of Toolkit elements.
1 2 3

Role MySite Document Manager (DMS::Document Manager) WebComponent My Favorite TV (WebTV::TV Receiver)

64

Chapter 3 Examples
This chapter presents two simple examples that illustrate the usage of CMS-IL. The rst example presented is the WebSite Template for a small personal website, consisting mainly of information that is relatively static (i.e., only updated by a select number of users). The second example consists of a simple Toolkit for viewing and managing folders and documents.

3.1
TODO

Personal WebSite

3.2
TODO

Document Management Toolkit

65

Chapter 4 Conclusion
In this manual, we have presented the CMS-IL language. The WebSite Template and Toolkit models have been explained in great detail, and their concepts have been dened. Finally, we have presented an example of both types of models: (1) a WebSite Template for a Personal WebSite; and (2) a Toolkit for performing some operations regarding Document management.

66