Validating formlets for Hunchentoot
An implementation of self-validating formlets for Hunchentoot.
- added support for field-type
show-formletnow accepts the keyword arg
:default-valueswhich takes a list of default values to populate the form with. These values will be used unless the user has already entered information, in which case their inputs will be displayed instead.
At the high level, form interaction in HTML requires
- Showing the user a form
- Getting the response back
- Running a validation function per form field (or run a single validation function on all of the fields)
- If the validation passed, sending them on, otherwise, showing them the form again (annotating to highight errors)
and I don't want to have to type it out all the time.
show-formlet call is all that should be required to display, validate and potentially re-display a form as many times as necessary.
Automatically wraps the generated form in a UL and provides CSS classes and ids as hooks for the designers, making the look and feel easily customizable with an external stylesheet.
Currently, it supports the complete set of HTML form fields excepting
radio-set (a stand-alone radio button is kind of pointless),
The system will eventually support higher-level inputs, like
The system assumes Hunchentoot + cl-who. This allows the internal code to take advantage of HTML generation, as opposed to tag
formatting, and make use of
post-parameters* and the Hunchentoot
session. That said, porting away from cl-who would only involve re-defining the
show methods, and porting away from Hunchentoot would involve re-writing the
show-formlet macros to accomodate another
The module is aimed at simplifying HTML form use for the developer. This is a place that's by definition bound by the slower of user speed or network speed. Furthermore, a single form is very rarely more than 20 inputs long in practice. Pieces will be made efficient where possible, but emphasis will not be placed on it.
While there are no assumptions about the CSS, formlet HTML markup is fixed in the
show methods. You can go in and re-define all the
shows, but that's about as easy as markup customization is going to get.
All that said, I have no experience working with CL servers other than hunchentoot, and
formlets is as fast as I need it to be at the moment, so if you'd like to change any of the above things, patches welcome.
Formlets now includes a number of predicate generators for external use. These cover the common situations so that you won't typically have to pass around raw
lambdas. They all return predicate functions as output.
The following four are pretty self explanatory. Longer/shorter checks the length of a string.
matches? passes if the given regex returns a result for the given input, and
mismatches? is the opposite.
not-blank? makes sure that a non-"" value was passed, and
same-as? checks that the field value is
string= to the specified value.
longer-than?:: Num -> (String -> Bool)
shorter-than?:: Num -> (String -> Bool)
matches?:: regex -> (String -> Bool)
mismatches?:: regex -> (String -> Bool)
not-blank?:: (String -> Bool)
same-as?:: field-name-string -> (String -> Bool)
The file predicates expect a hunchentoot file tuple instead of a string, but act the same from the users' perspective.
file-type? takes any number of type-strings and makes sure that the given files' content type matches one of them. You can find a list of common mimetypes here. It doesn't rely on file extensions.
file-smaller-than? takes a number of bytes and checks if the given file is smaller.
file-type?:: [File-type-string] -> (FileTuple -> Bool)
file-smaller-than?:: Size-in-bytes -> (FileTuple -> Bool)
Finally, the newly added set-predicates expect a list of values as input from the given field (these can only be used on
multi-select boxes and
checkbox-sets). They ensure that the number of returned values is (greater than|less than|equal to) a specified number.
picked-more-than?Num -> ([String] -> Bool)
picked-fewer-than?Num -> ([String] -> Bool)
picked-exactly?Num -> ([String] -> Bool)
To see some example code, check out the
test.lisp file (to see it in action, load the
formlets-test system and run the
formlets-test function, then check out localhost:4141). An example form declaration using a general validation message:
(define-formlet (login :submit "Login" :general-validation (#'check-password "I see what you did there. ಠ_ಠ")) ((user-name text) (password password)) (start-session) (setf (session-value :user-name) user-name) (setf (session-value :user-id) (check-password user-name password)) (redirect "/profile"))
If the validation function returns
t, a session is started and the user is redirected to
/profile. Otherwise, the user will be sent back to the previous page, and a general error will be displayed just above the form. The fields in this formlet are
user-name (a standard text input), and
password (a password input). The submit button will read "Login" (by default, it reads "Submit").
You would display the above formlet as follows:
(define-easy-handler (login-page :uri "/") () (form-template (show-formlet login)))
An instance of the
login is created as part of the
define-formlet call above. Calling
show-formlet with the appropriate formlet name causes the full HTML of the formlet to be generated. If any values appropiate for this formlet are found in session (or if you passed in a set using the
:default-values argument to
show-formlet), they will be displayed as default form values (passwords and recaptcha fields are never stored in session, so even if you redefine the
show method to display its value, it will not). If any errors appropriate for this formlet are present, they are
shown alongside the associated input.
An example form using individual input validation:
(define-formlet (register :submit "Register") ((user-name text :validation ((not-blank?) "You can't leave this field blank" #`unique-username? "That name has already been taken")) (password password :validation (longer-than? 4) "Your password must be longer than 4 characters") (confirm-password password :validation ((same-as? "password") "You must enter the same password in 'confirm password'")) (captcha recaptcha)) (let ((id (register user-name password))) (start-session) (setf (session-value :user-name) user-name) (setf (session-value :user-id) id) (redirect "/profile")))
You'd display this the same way as above, and the same principles apply. The only difference is that, instead of a single error being displayed on a validation failure, one is displayed next to each input. In this case, it's a series of 4 (recaptchas are the odd duck; they have their very own
validate method, which you can see in
recaptcha.lisp, so no additional declaration is needed). If all of them pass, the user is redirected to
/profile, otherwise a list of errors and user inputs is returned to
A single field declaration looks like this (the
validation parameter is a list of
((predicate-function error-message) ...)
(field-name field-type &key size value-set default-value validation)
- The field name is used to generate a label and name for the form field.
- The type signifies what kind of input will be displayed (currently, the system supports
recaptcha. A special note, in order to use the
recaptchainput type, you need to
formlets:*public-key*as appropriate for your recaptcha account.
A formlet declaration breaks down as
((name &key general-validation (submit "Submit")) (&rest fields) &rest on-success)
nameis used to generate the CSS id and name of the form, as well as determine the final name of this formlets' instance and validation handler.
fieldsshould be one or more form fields as defined above
submitis just the text that will appear on this formlets' submit button
- If the
general-validationis present, any field-specific validation values are ignored, and the form is validated according to this function/message sequence (
general-validationhere expects the same input as
validationin the field declaration). Any general validation functions are going to be
applyed to the list of all values for the formlet (for instance, in the
(list user-name password)
on-successis a body parameter that determines what to do if the form validates properly