| home / programming / awxml3 / 1 |    [previous][next] |
|
|
|
One way of simplifying this development process is to make business applications themselves aware of the need to deliver a Web user interface. This approach is followed by many of today’s popular middleware solutions, with some commercial database engines going so far as to incorporate a Web server into the database. However, making back-end business applications aware of the details of the user interface markup can make systems difficult to evolve and maintain. The resulting lack of separation of concerns ties Web applications to a particular back-end system.
As we deploy Web access to software at all levels of complexity ranging from business applications to electronic transactions, the problems outlined earlier can be better addressed by revisiting the essential underpinnings of the transactional Web. Today, Web applications need to be accessible from a variety of access devices and interaction modalities—Web applications may be accessed from a variety of clients ranging from desktop browsers to smart phones capable of delivering multimodal3 interaction. Thus, a travel application that is being deployed to the Web needs to be usable from within a desktop browser, a Personal Digital Assistant (PDA), and a cell phone equipped with a small display. Thus, the interface needs to be usable when interacting via a graphical or speech interface.
Notice that the problems with HTML forms outlined earlier become even more serious when confronted with the need to perform electronic transactions with a variety of different end-user devices and user interaction modalities.4 W3C XForms5—a revision to the existing HTML forms technology from 1993—builds on the advantages of XML to create a powerful forms module that can stand the Web in good stead for the next decade.
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.
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.
The Web developer models the various items of data to be collected as simple namevalue 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.
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.
| home / programming / awxml3 / 1 | [previous][next] |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: March 27, 2003
Revised: January 2, 2004
URL: http://webreference.com/programming/awxml3/
