blob: 0bbe81093036a1c413b92523bd5ab51dff8e2048 [file] [log] [blame]
------
Client-Side Validation
------
Jesse Kuhnert
------
26 July 2006
------
Client-Side Validation
Client side validation in Tapestry is now moving towards being just as powerful as its
server side counterpart, if not more so. To use the client side API all you need to do
is set the <<<clientValidationEnabled>>> parameter to <<<true>>> on your
{{{../components/form/form.html}Form}} and it will automatically be setup for you.
This document will focus on how you can customize and interact with the default tapestry javascript
validation system, leaving the normal {{{validation.html}Input Validation}} guide as the core resource
for configuring and using validation in general.
<<See also:>> Tapestry {{{../javascript/form.html}Form}} JavaScript API reference.
* Configuring CSS definitions
One of the largest changes made to Tapestry 4.1 was the complete replacement of most of the javascript
functions in the framework, including validation. As part of this change the new validation API doesn't
use window <<<alert>>> <alert('Clicked!')> dialogs anymore. The new system uses a
combination of {{{http://dojotoolkit.org}dojo}} dhtml widgets and <<<CSSS>>> rules to apply UI hints
to form fields with missing or invalid data.
There are now two core CSS classes that you must define for your input fields. There names are:
* <<fieldMissing>> - Applied to form input fields that are required and missing a selection/input value.
* <<fieldInvalid>> - Applied to form input fields that have <invalid> data. A field could be invalid for
a number of reasons, like an integer value not being within a certain range or a
{{{../components/form/datepicker.html}date}} field being in an invalid format.
[]
By default Tapestry <<does not>> define these two css classes, you must define them yourself in order to
see the classes applied to your forms. The TimeTracker demo application has defined these two css classes
as:
+----------------------------------------------
.fieldMissing {
background: #bedef4;
}
.fieldInvalid {
background: #ffaf7e;
font-weight: bold;
}
+----------------------------------------------
** Dojo dialog CSS definitions
This is still a questionable default, but for now the new way that error messages are presented to users
is with a client side {{{http://dojotoolkit.org}dojo}} Dialog widget.
[../images/UsersGuide/validation-dialog.png] Validation dialog example.
Much like the core validation system, the presentation of the validation dialog is also controlled by user
defined css rules:
* <<missingList>> - Applied to a block of <<< <ul><li>Message</li></ul> >>> html content for messages
resulting from missing fields.
* <<invalidList>> - Applied to a block of <<< <ul><li>Message</li></ul> >>> html content for messages
resulting from invalid fields.
[]
The TimeTracker demo application also defines a default set of classes to handle the dialog classes:
+-----------------------------------------------
.alertButton {
width: auto;
border: none;
background-color: #699ED9;
color: #fff;
padding: 0.1em;
border-bottom: 1px solid #5885b6 !important;
border-right: 1px solid #5885b6 !important;
border-top: 1px solid #92b8e2 !important;
border-left: 1px solid #92b8e2 !important;
cursor: hand;
cursor: pointer;
}
.alertDialog {
width: 30em;
border: 2px solid #ff660a;
padding: 1em;
background: #ffffff;
-moz-border-radius: 10px;
}
.alertContent .alertButton {
float:right;
position:relative;
bottom:1em;
}
.missingList, .invalidList {
padding-bottom: 0.6em;
padding-top: 0.2em;
padding-left:0.1em;
padding-right:0.2em;
margin: 0;
}
.missingList {
border-top: 4px solid #bedef4;
}
.invalidList {
border-top: 4px solid #ffaf7e;
}
.missingList li, .invalidList li {
list-style:none;
font-style:italic;
}
+-----------------------------------------------