Savory's Resources Library

Forms

Prudence provides easy access to HTML form parameters via the conversation.form API, and the Savory Resources library further adds easy conversion of the textual form to JavaScript types. However, robust HTML form support demands validation, including a mechanism to send internationalized validation error messages to the client.

Savory's Form class does this very well, supporting both server- and client-side validation via the same exact code, simultaneously! Additionally, it abstracts the form mechanism to allow for transparent support of AJAX forms, including Ext JS's powerful form and field widgets. The uniform API allows you to support various kinds of clients without changing your code.

This page is informational: go to the Ext JS Forms page to see some forms in action. The Authentication service, the Contact Us and Registration features also have some form demos.

Refer to the Savory.Resources API documentation for more details.

Server-Side Validation

In the pre-AJAX days, this was all we had: the server could either accept the POSTed HTML form and show the user a success page, or not accept it and show the form again, with an appropriate error message.

The problem, of course, is that this is slow and wasteful. The user has to wait for a round-trip to the server, and the server has to do the processing.

Client-Side Validation

Here, the client makes sure that the form is valid before sending it to the server. Great!

One potential limitation is that this is not always possible. For example, consider a user registering for a new site for the first time and must enter a unique username. It's impossible to send the entire list of usernames to the client side for validation. In this case, only the server can validate this field entirely. (Though, the client can still validate first that the username entered fits the requirements.)

Client-Side Masking

A variation or enchancement of client-side validation is the ability to allow for only certain characters to be types according to a pattern, usually a regular expression. For example, if the input must be an integer, you can accept only the digits 0 to 9, and the '-' sign to allow for negatives. This saves the user from wasting time by typing out inputs that will surely not be accepted anyway.

Both Client- and Server-Side Validation

Why enable both? What's the benefit of wasting processing on server-side validation when you can be sure that the client only sends validated data?

The answer is security: a hacker can easily create a client that does not include your validation code. Depending on what your application does with the form, this can lead to disasterous results. Consider the potential effect of these: negative currency amounts, dates in the past or the future, or even null fields. Enabling server-side validation, even with client-side validation in place, keeps you safe.

In many web development environments, enabling both is a considerable development effort, because the frontend and backend are likely written in different languages, requiring you to write the validation code twice. But Savory makes it trivial -- just set a flag -- to gain the benefits of both modes.