Navigational Context Design Pattern: An Implementation for Web Development

Flávio Azevedo de Lima, B.Sc.
R. T. Price, Eng., M.Sc., D.Phil.

Instituto de Informática*, UFRGS, Brazil
E-mail: {flima, tomprice}

*Amadeus Project, sponsored by CNPq and FAPERGS.


This paper presents an implementation of the Navigational Context hypermedia design pattern. This pattern has been proposed by Rossi, Schwabe and Garrido, but implementation alternatives have not been fully explored specially regarding Web applications. The approach presented in this paper employs features of the HTML language to implements the features specified by the design pattern.

KEYWORDS: Design Patterns, Hypermedia Design, HTML, Web Development.

1. Introduction

The main benefit of design patterns is the reuse of the design experience and/or structures [1, 2]. A design pattern catalogue has been proposed by Gamma et al. [1], and, many new patterns have been proposed [8, 9], including recent efforts towards patterns for hypermedia [2, 8]. This paper presents a new implementation approach to the Navigational Context hypermedia design pattern [2] suited for the characteristics and tools available for the Internet environment.

1.1 The Navigational Context Pattern

The Navigational Context pattern is based on the Decorator [1] (see figure 1 below). The goal of the Decorator pattern is to dynamically attach additional responsibilities to an object, in a flexible way not provided by sub-classing. In other words, Decorator detaches the object behaviour from some (or all) of the exhibition issues. By using the decorator pattern an object may dynamically receive additional features, depending on the context where it is being used, without changing its core features.

The Navigational Context Pattern benefits from the experience achieved from OOHDM [3]. The use of this pattern for hypermedia purposes, as presented in [2], employs characteristics of the Decorator pattern to include specific information about the context where a node is being displayed. It simplifies the modelling of the navigational structure of the application, because the access to information nodes is specified within the context. It also helps users not getting lost, because generic information regarding the context is displayed within the context node. However, the pattern description [2] is concerned only with the implementation on hypermedia environments, and explicitly states that the implementation for Web development may be difficult.

2 Web development and document management

One of the research areas of the Amadeus Project has been the modelling of Web Information Systems based on document management and workflow [4]. The goal is to achieve an integrated modelling methodology suited for the particular characteristics of the Web, involving documents, executable components, workflow, web browsers, and so on. To do so, a number of UML stereotypes [5] have been defined (for instance, «Document», «Context», «Executable Component», «Frame», and «Navigational Link») and modelling steps have been suggested. One of the challenges faced was the specification of access constraints in terms of roles played by different actors. Access constraints specify the concrete views of a document available for each actor. In the modelling methodology currently in development within the Amadeus Project it has been realised that this problem may be solved by the definition of contexts for actor and documents. Contexts are stereotypes that define how a document is shown. The relationships (accesses) among actors and documents are not direct; there is always a context between an actor and a document. The context is responsible for displaying the appropriate information contained in a document.

The definition of how a context relates to a document is modelled in a specific step of the methodology. Other important phases are uses cases, global navigational definition, structure of each document and data access constraints with contexts. Documents are often a composite of subdocuments with specific sets of information. For each root document, a number of contexts may be defined, depending on different access restrictions for each actor in the system. Each context must be modelled separately, specifying which and how subdocuments and smaller pieces of information will be displayed. A consequence of this approach is that a document is never responsible for displaying itself and its subdocuments.

2.1 Navigational Context extended

The combination of features from hypermedia development and document management for Web systems results in an extended design pattern with a particular implementation that:

3. HTML Features

This section briefly introduces some useful features of HTML that make possible the implementation of the concepts presented in the paper. The more important features are the Document Object Model (DOM, [6], [7]) and Cascading Style Sheets (CSS, [6]), in addition to JavaScript [6]. These tools allow a complete, dynamic manipulation of an HTML page, providing the ability to modify document for presentation in different contexts.

DOM is a great advance in HTML development. It combines HTML elements (treated, now, as objects), CSS, and script languages to manipulate both. DOM is an API for HTML and XML [6] documents. It specifies the attributes and methods of any element or tag found in an HTML or XML document. DOM also defines the logical structure of documents and the way a document is accessed and manipulated. DOM is an "object model" in the traditional object oriented design sense. Documents are modelled using objects, and the model encompasses not only the structure of a document, but also the behaviour of a document and the objects of which it is composed. JavaScript adds dynamic behaviour, manipulating the document elements defined by the DOM.

On the other hand, CCS lets the developer separate the content of an HTML document from their presentation. It defines, in an independent manner, how different HTML elements the browser will display. Therefore, it's possible to create a unique CSS with global rules that must be used by all documents in a site. For example, it's possible to decide that every <H1> must be displayed in blue by defining a rule like "H1 {color: blue}" within a style sheet. It's also possible to define styles for specific elements and declare element classes, among other possibilities.

4. Pattern Implementation

The Decorator pattern has the following structure [1]:

Figure 1: Decorator design pattern

ConcreteDecorators aggregate components, which may be another Decorator or a ConcreteComponent. The implementation here presented translates this structure into a simpler composition, where a document (a ConcreteComponent) may be directly aggregated by contexts (a ConcreteDecorator). There is no real need for the abstract classes, because HTML files do not have all the formal semantics of programming classes.

The extended Navigational Context, modelled with an UML stereotype based on Class, is an aggregation of HTML Frames, another stereotype. Each frame of the context is responsible by showing one subdocument, specifying which information will be displayed. The context may (and often do) provide additional frames or fields to show specific information and links. Figure 2 shows a Navigational Context definition, which has been implemented for experimentation. The notation used is the most recent outcome of the Amadeus Project, evolved from a previous work [4], and is explained below.

Figure 2: "Summarised Information" Navigational Context

The context "SummContext" is responsible by the navigation through a set of Staff pages, either teachers or students (this choice is specified in the "Index" document). The function of the context is to hide some of the information contained by the actual document. Two frames ("SummControlFrame" and "SummDisplayFrame") compose the context. "SummDisplayFrame" exhibits the "Staff" document. "SummControlFrame" implements additional functionality, providing links to other documents of the same type (teacher or student, as chosen), a link to the home page, and a description of the current context. The "SummScript" executable component contains the JavaScript code that manipulates the document. To specify how the context affects the document, every attribute and method of the document must be duplicated in the respective frame, with the appropriate changes in permissions. "SummDisplayFrame" shows an example: in the document, all attributes are invisible; in the frame, "name" and "email" are visible, but locked (this is a new convention not supported by Rational Rose, the tool currently in use).

To use the context, the user must specify the type of the staff in a previous page. When the context is loaded, it is responsible by retrieving the appropriate set of documents (in this example, the documents are hard coded in the script). Specific information and links are provided in an additional frame.

One of the advantages of this approach is the easy translation of the visual model to implementation HTML files and JavaScript code, because model elements are near to implementation elements. The example implementation contains the following HTML files:

The influence of the context over the documents is achieved with the use of the HTML features described before. The sequence of actions is:

1. User loads "_GlobalIndex.html"
   1.1. Document "_GlobalHidden.html" is loaded in a hidden frame
   1.2. Document "AppIndex.html" is loaded in the main frame
2. User selects the radio button "Teachers" in "AppIndex.html", for example
3. User clicks on the button "Summary" in "AppIndex.html"
   3.1. The function "onSumm( )" in "AppIndex.html" is executed
      3.1.1. Sets a global variable in "_GlobalHidden.html" to "teachers"
      3.1.2. Sets a global variable in "_GlobalHidden.html" to "summary"
      3.1.3. Calls function "loadContext( )" in "_GlobalHidden.html"  Loads "SummaryContext.html" in the main frame
   Loads "_Null.html" in the "display" frame
   Loads "SummControl.html" in the "control" frame
      Loads first teacher document  in the "display" frame
         Calls "doContext( )" in "SummControl.html"
            Shows the appropriate attributes of the document
While modelling the document, the designer must be aware of the contexts in which the document will be displayed to decompose the document into appropriate subdocuments. Each subdocument must also be designed with the contexts in mind, to achieve an adequate modelling of its elements.

Although the example is simple, it makes clear the great opportunities open by the use of the DOM and script languages for the implementation of Navigational Contexts. For example, the type of user may be identified in a login page and then appropriate contexts may be automatically chosen.

5. Conclusion

An alternative implementation for the Navigational Context has been presented. It uses advanced characteristics of HTML to implement the features defined by the pattern. The additional features obtained from this approach

This work is currently under development within the scope of the Amadeus Project and will be part of a master's thesis.

[1]    E. Gamma; R. Helm; R. Johnson; J. Vlissides. Design Patterns Ų Elements of Reusable Object-Oriented Software. Reading: Addison Wesley Longman, 1995.

[2] G. Rossi; D. Schwabe; A. Garrido. Design Reuse In Hypermedia Applications Development. Proceedings of the Eight ACM International Conference on Hypertext, Southampton, 1997.

[3]        D. Schwabe; G. Rossi; S. Barbosa. Systematic Hypermedia Design With OOHDM. Proceedings of the Seventh ACM International Conference on Hypertext, Washington, 1996.

[4]   F. A. de Lima; R. T. Price. Towards an Integrated Design Methodology for Internet-based Information Systems. Fifth International Workshop on Engineering Hypertext Functionality, in conjunction with the International Conference on Software Engineering. Kyoto, 1998. Available on WWW at

[5]    H-E Eriksson; M. Penker. UML Toolkit. New York: Wiley Computer Publishing, 1998.

[6]     E. Holzschlag. Special Edition Using HTML 4, Fifth Edition. Que Education & Training, 1998.

[7]  Document Object Model (DOM) Level 1 Specification, W3C Recommendation 1 October, 1998. Available on WWW at

[8]      C. Schmidt (editor). Pattern Languages of Program Design. Addison-Wesley, 1995.

[9]      C. Larman. Applying UML and Patterns: an Introduction to Object-Oriented Analysis and Design. Prentice-Hall PTR, 1997.