- Background
- A Simple Web Application
- XForms Components
- Summary of XForms Benefits
- XForms at a Glance
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.2 A Simple Web Application
This section introduces a simple Web application developed using today’s HTML forms and illustrates the various software modules that would be authored on the client and server to deploy a complete end-to-end solution. This sample application will be recast using XForms in the remaining sections of this chapter to illustrate the advantages inherent in the various components making up the XForms architecture.
1.2.1 Questionnaire Form
Consider a questionnaire application that collects the following items of user information:
|
name |
User’s first and last names as strings |
|
age |
User’s age as a number |
|
gender |
User’s gender: m for male and f for female |
|
birthday |
Fields making up the user’s date of birth |
|
address |
Fields making up the user’s mailing address |
|
|
User’s email address as a string |
|
ssn |
User’s Social Security number, if available |
Data collected by this questionnaire will be communicated to a survey application that imposes the following validity constraints on the data:
-
All requested data items must be provided.
-
Values must be legal for each field; for example, value of field age must be a number; fields making up the value of birthday need to be valid date components.
-
Field ssn must contain a 9-digit Social Security number; if none is available, a default value of 000-000-000 must be used.
1.2.2 Developing the Web Application
The Web developer models the various items of data to be collected as simple name-value pairs; for example, age=21. Compound data items like address and name are made up of subfields, and in modeling these as simple string value pairs, the developer introduces additional field names such as name.first. Here is a list of the field names the developer might create for this application:
|
name.first |
name.last |
age |
|
address.street |
address.city |
address.zip |
|
birthday.day |
birthday.month |
birthday.year |
|
|
ssn |
gender |
Next, the developer creates the server-side software component that will receive the submitted data as name-value pairs—this typically starts off as a stand-alone CGI script that evolves to encompass more and more functionality as the application gains in sophistication. Functions performed by this component include:
-
Produce the HTML page that is displayed to the user; this generates the initial user interface and displays default values if any.
-
Receive submitted data as name-value pairs via HTTP.
-
Validate received data to ensure that all application constraints are satisfied.
-
Generate a new HTML page that allows the user to update previously supplied values if one or more fields are found to be invalid.
-
Make all fields sticky, that is, user does not lose previously supplied values during client-server round-trips.
-
Marshal the data into a structure that is suitable for the survey application when all fields have valid values. This is necessary because intermediate fields created by the Web developer such as name.first may not match what the survey application expects.
-
Transmit the collected data to the back-end, process the resulting response, and communicate the results to the user by generating an appropriate HTML page.
1.2.3 Developing the User Interface
The user interface is delivered to the connecting browser by producing appropriate HTML markup and transmitting this markup via HTTP to the user’s browser. Interaction elements, for example, input fields, are contained in HTML element 〈form〉 that also specifies the URI where the data is to be submitted; the HTTP method to use, for example, GET or POST; and details on the encoding to use when transmitting the data. HTML markup for user interface controls, for example, 〈input〉, is used to create input fields in the resulting user interface. This markup refers to the field names defined earlier, for example, name.first, to specify the association between the field names defined by the Web developer and the values provided by the end user. The markup also encodes default values, if any, for the various fields. Notice the tight binding between the HTML markup and the server-side logic developed earlier with respect to the following:
-
Field names used in the HTML markup need to match the names used in the server-side component.
-
Making all fields sticky, that is, retaining user supplied values during multiple client-server round-trips requires that the previously received values be embedded in the generated HTML.
To achieve this, early Web applications produced the HTML markup from within the CGI script. Though this works in simple cases, this approach does not scale for creating more complex Web applications. This is because of the lack of separation of concerns that results from mixing user interface generation with server-side application logic. Maintaining and evolving the user interface markup require the developer to edit the server-side component. However, the skills required to edit server-side software components are different from those needed to design good user interfaces. This increases the cost of designing good Web user interfaces and makes it tedious to keep the result synchronized with the software components that implement the interaction.
1.2.4 A More Sophisticated Implementation
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.
)
Figure 1.1. A simple Web application made up of software components that together implement server-side validation and client-side user
interaction.
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.
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.