Writing to the server

193

response is interpreted purely as visual markup typically affecting a single rectangular region of the visible UI. XSLT is discussed in more detail in chapter 11. Problems and limitations

The main limitation of a data-centric approach is that it places the burden of parsing the data squarely on the client. Hence the client-tier code will tend to be more complicated, but, where this approach is adopted wholesale in a larger application, the costs can be offset by reusing parser code or abstracting some of the functionality into a library.

The three approaches that we have presented here arguably form a spectrum between the traditional web-app model and the desktop-style thick client. Fortunately, the three patterns are not mutually exclusive and may all be used in the same application.

Client/server communications run both ways, of course. We’ll wrap up this chapter with a look at how the client can send data to the server.

5.5 Writing to the server

So far, we’ve concentrated on one side of the conversation, namely, the server telling the client what is going on. In most applications, the user will want to manipulate the domain model as well as look at it. In a multiuser environment, we also want to receive updates on changes that other users have made.

Let’s consider the case of updating changes that we have made first. Technically, there are two main mechanisms for submitting data: HTML forms and the XMLHttpRequest object. Let’s run through each briefly in turn.

5.5.1 Using HTML forms

In a classic web application, HTML form elements are the standard mechanism for user input of data. Form elements can be declared in the HTML markup for a page:

This will render itself as a couple of blank text boxes. If I enter values of dave and letmein on the form, then an HTTP POST request is sent to myFormHandlerURL.php, with body text of username=dave&password=letmein. In most modern web programming systems, we don’t directly see this encoded form Licensed to jonathan zheng

194

CHAPTER 5

The role of the server

data but have the name-value pairs decoded for us as an associative array or

“magic” variables.

It’s fairly common practice these days to add a little JavaScript to validate the form contents locally before submitting. We can modify our simple form to do this:

And we can define a validation routine in the JavaScript for the page: function validateForm(){

var form=document.getElementById('myForm');

var user=form.elements[0].value;

var pwd=form.elements[1].value;

if (user && user.length>0 && pwd && pwd.length>0){

form.action='myFormHandlerURL.php';

form.submit();

}else{

alert("please fill in your credentials before logging in");

}

}

The form is initially defined with no action attribute. The real URL is substituted only when the values in the form have been validated correctly. JavaScript can also be used to enhance forms by disabling the Submit button to prevent multiple submissions, encrypting passwords before sending them over the network, and so on. These techniques are well documented elsewhere, and we won’t go into them in depth here. Chapters 9 and 10 contain more detailed working examples of Ajax-enhanced HTML forms.

We can also construct a form element programmatically and submit it behind the scenes. If we style it to not be displayed, we can do so without