| home / programming / awxml3 / 1 |    [previous] [next] |
|
|
|
The lack of separation of concerns that arises when incorporating presentational markup within executable CGI scripts is typically overcome by developing Web applications using more sophisticated server-side technologies such as Hypertext Preprocessor (PHP),6 Java Server Pages (JSP)7 or Active Server Pages (ASP).8 All of these technologies follow a Model, View, Controller (MVC) decomposition by factoring out the user interface markup from the program code that implements the server-side application logic. Thus, the user interface is created as an XML9 document with special tags that invoke the appropriate software components when processed by the server. As a result, the user interface designer can work with intuitive authoring tools that generate XML markup while the software developer builds software objects using traditional programming tools.
Thus, the simple Web application developed earlier would be created as a set of software objects that implements the validation and navigation logic and a set of markup pages used to generate the user interface at each stage of the interaction— see Figure 1.1 for a high-level overview of the resulting components and their interdependencies.
Higher level Web application frameworks, such as struts10 based on JSP and servlets, provide further abstractions that allow the Web developer to create the application by defining the model as Java beans, defining the user interaction views as JSP pages, and wiring up the resulting model and views via a standard controller component that manages the navigation among the various views.
6http://www.php.net
7http://java.sun.com/products/jsp
8http://www.asp.net/
9http://www.w3.org/tr/REC-xml.html
10http://jakarta.apache.org/struts
Client-side validation Process UI Events
Figure 1.1. A simple Web application made up of software
components that together
implement server-side validation and client-side user interaction.
Finally, an interface where the user learns about invalid input only after submitting the data to the server can prove unsatisfactory. To achieve a rich interactive end-user experience, simple tests such as checking for valid values for age or birthday are better performed on the client during user interaction to provide immediate feedback. This is achieved by embedding client-side validation scripts in the HTML markup. Notice that such validation code duplicates the validation rules already authored as part of the server-side validation component, but this time in a client-specific scripting language. Variations in the scripting environment provided by Web browsers on various platforms make such scripts hard to develop, test, and maintain.
The previous section traced the development of a simple Web application using present-day technologies predicated by the HTML forms architecture. The questionnaire application evolved from a simple stand-alone CGI script to a more complex Web application consisting of software components dedicated to managing the application state within a servlet, markup pages designed to create the user interaction, and navigation components designed to connect the various views with the application state. In doing so, we saw that the Web developer needed to implement significant application-specific functionality in custom software to deliver the questionnaire to a Web browser.
XForms leverages the power of using XML in modeling, collecting, and serializing user input. XForms has been designed to abstract much of this functionality into a set of components that enable the Web developer to rely on a standard set of services and off-the-shelf XML tools when developing the final Web application. This allows the Web developer to focus on key aspects of the application and rely on the underlying XForms platform for the following services:
• Produce user interfaces appropriate for the connecting device.
• Provide interactive user feedback via automated client-side validation.
• Validate user input on the server automatically.
• Marshal user input on the server into a structure suitable for the back-end
application.
Based on what has been observed in the design of today’s Web applications and the need to deliver such applications to an ever-increasing array of end-user devices, the overall XForms architecture has been divided into the following components. A key feature of this MVC decomposition is a clear separation of the model from its final presentation.
| Model | All nonpresentational aspects of a Web application are encapsulated by the XForms data model. The data model incorporates an XML instance that holds user input, the constraints used to validate this input, and the necessary metadata about how this user input should be communicated to the Web server. |
| UI | XForms defines a user interface vocabulary that consists of abstract controls and aggregation constructs used to create rich user interfaces. The user interface vocabulary is designed to capture the underlying intent of the user interaction, rather than its final presentation on any given device or in any specific modality. This makes it possible to deliver XForms-based Web applications to different devices and modalities. |
| Submit | This allows the Web application author to specify where, how, and what pieces of data to submit to the Web server. It also permits the application developer to specify what actions to take upon receiving a response from the server. |
Next, we reexamine the questionnaire and recast it as an XForms application. The questionnaire will be created as an XHTML document that contains the XForms model and user interface components. The following subsections detail each of these components and show how they are used within an XHTML document. The XForms model (contained in ~model~) is placed within XHTML element ~head~. XForms user interface controls create the user interaction and appear within the body of the document, that is, within XHTML element ~body~, and are rendered as part of the document content. In this overview, we will describe a few of the XForms user interface controls to give the reader a feel for XForms markup; subsequent chapters will detail all the constructs defined in XForms 1.0.
As before, we start by enumerating the various items of user information collected by the Web application. Since we are now using XML, we no longer need restrict ourselves to a flat data model consisting of a set of untyped name-value pairs. Instead, we encapsulate the information collected from the user in a structured XML document. This is called the XML instance. Further, we pick the structure of this XML instance to suit the survey application—see Figure 1.2.
Figure 1.2. Element ~instance~ declares the
XML template that holds
user input and default values.
Figure 1.3. Constraining instance data by specifying an XML
Schema.
Notice that compound data items such as address are now modeled to reflect the structure of the data, unlike when using flat name-value pairs. This also obviates the need to introduce intermediate fields to hold portions of the user data and the subsequent need to marshal such intermediate fields into the structure required by the application.
Next, this XML instance can be annotated with the various constraints specified by the application, for example, age should be a number. When using XML, such constraints are typically encapsulated in an XML Schema11 document that defines the structure of the XML instance—see Figure 1.3.
Alternatively, such type constraints can be specified as part of the instance using attribute xsi:type12 as shown in Figure 1.4. Both techniques have their place in Web development; the former is especially relevant when creating Web applications that access existing business logic, and the latter is useful when creating a one-off Web application with relatively simple type constraints.
In the questionnaire application, the constraints shown in Figure 1.4 encapsulate type constraints—the default type is string. Complex schemas typically encapsulate more constraints, such as specifying the rules for validating a 9-digit Social Security Number or specifying the set of valid values for the various fields. Note that this example has been kept intentionally simple—later chapters will build real-world examples where we will use the full richness of the built-in type mechanisms provided by XML Schema.
The advantage of specifying such constraints using XML Schema is that the developer can then rely on off-the-shelf XML parsers to validate the data instance against the supplied constraints. With the increasing adoption of XML Schema by database vendors, complex business applications are likely already to have an XML
11http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/ [Link adjusted. - Ed.]
12Attribute xsi:type is defined by XML Schema.
Figure 1.4. XML representation of the data collected by a questionnaire
application, along
with some simple type constraints.
Schema definition for the data model, and the developer can leverage such existing assets when creating a Web application. XML processor xerces13 is available from the Apache project implements XML Schema and can be used to validate data collected on the server.
Finally, the constraints on the data instance are now encapsulated in declarative
XML—as opposed to imperative program code—thus making it easier
to maintain and revise these constraints using XML-aware tools without having
to reprogram the application.
| home / programming / awxml3 / 1 | [previous] [next] |
Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Tech Jobs | Shopping | E-mail Offers
Created: March 27, 2003
Revised: January 2, 2004
URL: http://webreference.com/programming/awxml3/
