O'Reilly logo

Learning WML, and WMLScript by Martin Frost

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 4. WML User Interaction

The previous two chapters described some of the features found in WML that don’t exist in HTML. This chapter covers the features that WML provides to receive input from the user, and most of these are much more powerful than their equivalents in HTML.

The main reason for this extra power is that WML has variables. In HTML, you can have controls such as pulldown menus or text input fields, but you can use these in only limited ways: in an HTML form, which allows you to collect a number of controls and send their results to a server for processing, or with Java or JavaScript, which are complete programming languages built into the web browser.

Problems with Web Interaction

Using HTML forms for this purpose suffers from one major problem: the processing has to be done on the server. The client displays the controls, collects their results, packages them, and sends them to the server, but that’s it. Apart from some simple constraints such as the maximum length of the text in an input box, you can’t even check the input for validity before sending it off. This results in a lot of extra network connections, slowing things down a lot, even on a fast Internet link. Imagine how slow all those extra network connections are on a much slower link, as WAP has to contend with.

Using Java or JavaScript to collect the input does allow local processing, but they come complete with their own sets of problems. For a start, they both require a lot more from the browser: most older browsers have either no support for these or very limited or buggy support, which makes it harder to write pages that work across all browsers. Most text-only browsers don’t support these at all. (Yes, some people do still use text-only browsers.)

Another, subtler problem with the Web’s way of doing these things is that there are multiple ways to declare the controls. Suppose you want to display a text input box. Using a form, you can use something like:

<INPUT TYPE="TEXT" NAME="wibble">

Using JavaScript with the HTML, possibly:

<INPUT TYPE="TEXT" NAME="wibble" ONCHANGE="wibble_chg( );">

If using Java applets, something like:[8]

TextField wibble = new TextField ( );
add (wibble);

Each of these fragments has to be referenced in a completely different way from within the HTML page that forms the skeleton. Furthermore, the same control has to be added to the page in three different ways, even though they are all drawn in the same way by the browser, and the user interacts with each in the same way. This makes it hard to change the action of a control once it has been implemented. It requires rewriting everything related to that control, and probably restructuring the whole page as well.



[8] It isn’t completely fair to compare Java with HTML here, since Java is a full-featured programming language, and HTML is just a markup language. But since Java is often used to implement this sort of thing on web pages, it’s appropriate to mention it here.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required