CSCI 6962: Server-side Design and Programming

Validation Tools in Java Server Faces

Form Validation• Detecting user error

– Invalid form information – Inconsistencies of forms to other entities

• Enter ID not in database, etc.

• Correcting user error– Providing information or how to correct error– Reducing user memory load

• Preventing user error– Good instructions– Field types/values that prevent error– Error tolerance

• Example: Accepting phone numbers in multiple formats

Error Pages

• Put error message next to source of error– Allows user to see where correction is needed

Adding Error Messages to Pages

• Generating messages in bean (old school JSP idea)– Error messages member variable of bean– Output field linked to that value

• Using built-in validators in JSF page– Required fields– Range validation– Regular expression

• Custom validator beans– Still in beta stage

Bean Generated Messages

• Each form element has corresponding outputLabel for error message

• outputLabel linked to member variable in bean– Initially empty string so no message visible at first

Bean Generated Messages

• Member variable changed to appropriate error message if that value is invalid

Built-in Validators

• Required validators– Attribute in most JSF form tags– Should specify a corresponding requiredMessage to be

displayed if field not present

– Error message displayed at bottom of form by default

Built-in Validators

• Associate error message to <h:message tag – Give the field an id attribute– Place <h:message tag at desired location next to field– Give it a corresponding for attribute to link to id

Other Built-in Validators

• Format:

<h:inputText id=“id” validatorMessage=“message”> <f:validateSomething attributes></h:inputText>

Type of validation doneMessage displayed if invalid

Other Built-in Validators

• Tags:– <f:validateLongRange/>

Validates value is integer– <f:validateDoubleRange/>

Validates value is a number– <f:validateLength/>

Validates string length between limits– <f:validateRegex/>

Validates against regular expression– <f:validateRequired/>

Can use in place of required attribute

Numeric Validators

• Can also set minimum and/or maximum legal values:

Fails if not integerFails if < 1

Error message diplayed

Regular Expression Validators

• Specify pattern attribute to match:

Limits of Built-in Validators

• Limited abilities– Required validator does not automatically trim, etc.

• Limited error message capability– Can only display single error message (other than required

message) even if multiple validators used• Cannot combine with form-based validation

– Page-based validation done first– If fails, action method of command element not called

• Advantage: Web designer controls error messages– Possibly better understanding of user

Custom Validators

• Can create own validators for cases not covered by built-in validators– Specific support class for each form (implements Validator

interface)– Throws ValidatorExecption containing error message– Handled by <f:validator tag

• Main limit: Can only detect problems in single form element it is associated with– Cannot validate credit card expiration, for example

Custom Validators• Separate class (no easy way to create in NetBeans)

Required libraries to import

ID for access by JSF pages

Implements Validator interface

Has validate method with these parameters (called by JSF page)

Custom ValidatorsValue entered into field extracted from value paramter

Do validation and set error message

Must convert it into a String to access it

Custom Validators

Throw back to JSF page, where it will be displayed in message tag associated with form element

If not valid, construct a FacesMessage object from error message

Custom Validators

Validator tag linked to validator class

• When page sumitted, validate method of QuantityValidator called

• If ValidatorException thrown, its message displayed

Last Resort Error Handling

• User should never see Tomcat-generated error page!– Reduces confidence in your entire site– Confuses user (did they do something wrong?)

Last Resort Error Handling

• “Last Resort” error page called if unhandled error– Identifiable company logo and design

so the user can be sure that they are still on your site

– Main navigation bar which offers user a way to try something else

– A reassuring message telling this is not user’s fault

– A link to email the webmaster to inform them of the problem

– Note: may need to be >512 chars to fool IE

Default Error Pages

• Can specify default page for:– Unhandled exceptions

(such as NumberFormatExceptions)– Missing pages and other server-related errors

• Done in web.xml file– Error pages under pages tab

Default Exception Handling

• Specify page to jump to and type of exception

– Must use full name of class (including library.package.classname)

– Can use base class java.lang.Exception to catch everything

• If this type of exception occurs and is not handled inside a try/catch, jump to this page

Handling Missing Pages

• Unavoidable in complex web sites with multiple developers

• Causes error code 404

• If this error code occurs within, jump to this page