Feature

This article aims to illustrate how loose coupling of a Model in an MVC-based framework can be achieved by describing a real example - developing a framework for a Web-based XSD-XML generator, which is part of the Event Web research at the Infospheres Lab at Caltech. Why this is important is explained, along with a description of the various techniques used to accomplish the goal. Examples include: how a Model can be initiated in a modular manner; how to add dynamic properties to a Model without polluting the Model base classes; how to change the Model without affecting its existing operations; how the Model can be switched during runtime without affecting interactions with other components; how all these can be done if the Model is complex as in a DOM structure and is generated dynamically. Design patterns are largely employed to construct the framework; how the Eclipse XSD API should be used is also illustrated.

Why Only Controller and View?
When people discuss MVC they concentrate on View and Controller, asking "How can the View be changed easily to enhance user interface?" and "How can the Controller be easily changed to enhance the algorithm to handle user input?" Apache Struts, a Java Web application framework, is a very successful application of the MVC paradigm. Not surprising, Struts is also mainly concerned with View and Controller. They are linked flexibly - new Controllers can be added by sub-classing the Action class, and can be easily linked to Views as specified in a configuration file. In the same way, new Views can be easily linked to the old Controller by changing the configuration file. ActionForms are available to facilitate communication between the View and Controller (see Figure 1).

Struts is successful because its framework is sufficient to handle most Web application development. Changes always take place in the Controller and View, e.g., the calculation of a discount in an online store frequently changes; the appearance of the Web application is often changed to enhance the user experience.

Why, then, would people ignore the Model? It's because the Model is typically static. For example, the customer and price model remains the same in most online shopping applications. So tight coupling between the Model and other components would normally not be a major problem during redevelopment. It's therefore reasonable for an MVC-based framework to put less emphasis on the Model. However, this isn't true in some cases, as shown in the XSD-XML Web generator below.

Model Matters
The XSD-XML Web generator here is part of the Event Web, developed in the Caltech Infospheres Lab headed by Professor K. Mani Chandy and Dr. Daniel M. Zimmerman. For more details, please refer to www.infospheres.caltech.edu. In this project, a Web portal is developed for users to interact with the Event Web and part of its functionality is to help users specify an XML file based on an XSD. In other words, an XSD-XML Web generator is needed with the flow chart shown below: (see Figure 2)

Only a simplified version of the generator is developed for the prototype. However, redevelopment is needed when:

1. More XSD features are supported to describe complex XML instances, e.g., annotations and attributes. The parsing process then becomes more complicated.
2. The XSD uses features (such as group and choices) that could generate XML instances with different structures. This means the users can choose their own DOM structure and dynamic UI is needed.
3. The type definition becomes more complicated. For example, the element content consists of an SQL statement to describe the price range "(Price < 10 AND Price >2) AND Price <> 5". In this case, an interactive tool is needed to help users specify the input and analysis on user input is needed (see Figure 3).

Redevelopment- re-reading the code and modifying the program while preserving some of the operations - isn't pleasant. The framework exists to help programmers understand the program and know exactly what to change to make an enhancement without affecting the entire program. An MVC-based framework is a natural choice here and the major components can be easily identified as:

1. View - the input form
2. Model - the DOM structure generated by parsing the XSD
3. Controller - the link between View and Model to analyze user input and update the Model, responsible for forwarding a new View to the user

Loose coupling of the Model plays a crucial role in this framework. The Model here is the DOM structure generated dynamically from the XSD file and redevelopment to support more complex XSD would give rise to the following design issues:

1. When more features of XSD are supported, the algorithm for generating the forms/files has to be changed. How can this be done without affecting the algorithm that manipulates the Model?
2. New operations like analyzing user input may be needed in complicated type definition. How can that be added without making the Model aware of it?

These two problems are related to how the Model is coupled with the other parts of the framework. In addition, our Model is generated dynamically by parsing an XSD. In complex events where users are allowed to define their own DOM structures, how can the Model be changed and presented by the Controller and View efficiently, given that the Model is not known until runtime?

The complexity of the XSD specification makes these problems worse. Manual effort is needed to determine how each XSD feature should be interpreted in making a form and generating the XML. For example, element declaration and type definition describes what the DOM structure should be like, facets of simple types specify how error checking should be done, and model groups specify the different forms of DOM structures that users can choose from. For the sake of completing the background information before discussing the framework design, we will briefly discuss XSD parsing here, which is how the Model is initiated. A tree structure shown in the following diagram is formed when the example XSD is parsed using Eclipse XSD API.

A common mistake is to assume that the tree structure generated by parsing the XSD is exactly the DOM structure of the target XML file, which is clearly not the case as shown. As mentioned, an XML instance specified by a XSD can have alternate DOM structures, so it doesn't make sense to expect that parsing the XSD will generate the corresponding DOM structure directly. Additional manipulation is needed to create the DOM tree of the target XML instance from the tree structure above. The corresponding DOM structure is shown below.

Shaping the Framework
One trivial way to structure the Model would be to build a DOM tree directly when parsing the XSD file. But such an approach has disadvantages:

1. DOM handling is both memory-hungry and computationally expensive, especially when users are allowed to re-structure the tree.
2. Some information such as the type of text node and possible alternate DOM structures can't be stored in DOM. Additional data structures are needed.
3. The processes of creating the DOM tree and parsing the XSD are tightly coupled, i.e., the process of parsing the XSD isn't made modular. When more XSD features have to be supported, the entire process can be affected. So can we fake a DOM tree to overcome these constraints?

Let's begin by building a family of Element objects that contain properties specifying the tag names, type information, etc. They go into ArrayLists and are linked together like a DOM tree as shown below. The Elements are classified by their types as specified in the XSD (e.g., simple type, complex type, etc.) (see Figure 4).

While building our DOM structure after the XSD is parsed, Elements of different types know the different forms of data they are looking for. For example, a built-in type element only looks for the tag name and the built-in type. A complex type element looks for the other elements that make up the complex type as well as the model groups that structure the nested elements. As a result, the parsing process becomes modular - each Element knows how to parse itself. When more advanced XSD features are needed, like group referencing in elements of complex types, only the parsing method of ComplexTypeElement has to be changed. How the other elements are parsed isn't affected. This technique can also be used to build an abstract syntax tree for a compiler or interpreter (see Figure 5).

What's more, sub-classing can be done to support even more complicated elements (e.g., elements referencing substitution groups). Since they have the same interface for providing information, adding more Elements in the Model is transparent to the other components. For example, View calls the same "getTag" method on the Elements without knowing their concrete classes.

But this doesn't completely solve the problem of supporting extra XSD features. For example, sub-classing the Element won't support simple type elements with different facets, because 'simple type with facet' isn't classified as another type, and sub-classing like this would lead to an explosion of classes. Nor it is desirable to rewrite the entire SimpleTypeElement class to specify how the facet should be handled. In including attributes, the attributes should be added to the individual Element object instead of the entire class, since every Element doesn't need attributes, but this can only be determined at runtime when the XSD is parsed. To address this, a Decorator pattern can be used to attach additional responsibilities to an object dynamically without polluting the Element class:

1. Information about these additional features is stored in the Decorators.
2. The handling of these additional features (e.g., parsing) can be delegated to the Decorators.

A Decorator can even be composed with another Decorator to enhance its functionality according to the Composite pattern. For example, Attribute can own a Facet Decorator for specifying the attribute type.

To sum up, we have now described how our defined DOM structure can support different features of XSD for generating the input form and the XML file - a family of Elements is defined and different Decorators (additional features) contribute to different aspects of the Element. For example, Facet represents the validity of the node values. Of course it should be noted that the Element should only be a data keeper, except in the case of parsing, since only it knows how to initialize itself. How it's manipulated, (say represented in a form) is delegated to other parts of the framework (see Figure 6).