Common Lisp Package: FORMLETS

A package implementing auto-validating formlets for Hunchentoot



An implementation of self-validating formlets for Hunchentoot.


  • added support for field-type hidden
  • show-formlet now accepts the keyword arg :default-values which 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.


Boilerplate elimination At the high level, form interaction in HTML requires

  1. Showing the user a form
  2. Getting the response back
  3. Running a validation function per form field (or run a single validation function on all of the fields)
  4. 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.

Simplicity A define-formlet and show-formlet call is all that should be required to display, validate and potentially re-display a form as many times as necessary.

Style 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.

Completeness Currently, it supports the complete set of HTML form fields excepting reset (hidden, password, text, textarea, file, checkbox (and checkbox-set), radio-set (a stand-alone radio button is kind of pointless), select (and multi-select)) and recaptcha. The system will eventually support higher-level inputs, like date or slider.


Portability 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 define-formlet and show-formlet macros to accomodate another session and POST model.

Run-time efficiency 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.

Markup customization 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.


Predicates 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)

Tutorial 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))  
  (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 formlet named 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 passwordshow 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:

(def-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)))  
    (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 register-page.

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 text, textarea, password, file, checkbox, select, radio-set, multi-select, checkbox-set or recaptcha. A special note, in order to use the recaptcha input type, you need to setf the formlets:*private-key* and 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) 
  • name is 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.
  • fields should be one or more form fields as defined above
  • submit is just the text that will appear on this formlets' submit button
  • If the general-validation is present, any field-specific validation values are ignored, and the form is validated according to this function/message sequence (general-validation here expects the same input as validation in 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 login example above, check-password would be applyed to (list user-name password)
  • Finally, on-success is a body parameter that determines what to do if the form validates properly

















Takes a terse declaration and expands it into a make-instance for macro purposes


Sends a HTTP request to a web server and returns its reply. URI is where the request is sent to, and it is either a string denoting a uniform resource identifier or a PURI:URI object. The scheme of URI must be `http' or `https'. The function returns SEVEN values - the body of the reply (but see below), the status code as an integer, an alist of the headers sent by the server where for each element the car (the name of the header) is a keyword and the cdr (the value of the header) is a string, the URI the reply comes from (which might be different from the URI the request was sent to in case of redirects), the stream the reply was read from, a generalized boolean which denotes whether the stream should be closed (and which you can usually ignore), and finally the reason phrase from the status line as a string. PROTOCOL is the HTTP protocol which is going to be used in the request line, it must be one of the keywords :HTTP/1.0 or :HTTP/1.1. METHOD is the method used in the request line, a keyword (like :GET or :HEAD) denoting a valid HTTP/1.1 or WebDAV request method, or :REPORT, as described in the Versioning Extensions to WebDAV. Additionally, you can also use the pseudo method :OPTIONS* which is like :OPTIONS but means that an "OPTIONS *" request line will be sent, i.e. the URI's path and query parts will be ignored. If FORCE-SSL is true, SSL will be attached to the socket stream which connects Drakma with the web server. Usually, you don't have to provide this argument, as SSL will be attached anyway if the scheme of URI is `https'. CERTIFICATE is the file name of the PEM encoded client certificate to present to the server when making a SSL connection. KEY specifies the file name of the PEM encoded private key matching the certificate. CERTIFICATE-PASSWORD specifies the pass phrase to use to decrypt the private key. VERIFY can be specified to force verification of the certificate that is presented by the server in an SSL connection. It can be specified either as NIL if no check should be performed, :OPTIONAL to verify the server's certificate if it presented one or :REQUIRED to verify the server's certificate and fail if an invalid or no certificate was presented. MAX-DEPTH can be specified to change the maximum allowed certificate signing depth that is accepted. The default is 10. CA-FILE and CA-DIRECTORY can be specified to set the certificate authority bundle file or directory to use for certificate validation. The CERTIFICATE, KEY, CERTIFICATE-PASSWORD, VERIFY, MAX-DEPTH, CA-FILE and CA-DIRECTORY parameters are ignored for non-SSL requests. PARAMETERS is an alist of name/value pairs (the car and the cdr each being a string) which denotes the parameters which are added to the query part of the URL or (in the case of a POST request) comprise the body of the request. (But see CONTENT below.) The values can also be NIL in which case only the name (without an equal sign) is used in the query string. The name/value pairs are URL-encoded using the FLEXI-STREAMS external format EXTERNAL-FORMAT-OUT before they are sent to the server unless FORM-DATA is true in which case the POST request body is sent as `multipart/form-data' using EXTERNAL-FORMAT-OUT. The values of the PARAMETERS alist can also be pathnames, open binary input streams, unary functions, or lists where the first element is of one of the former types. These values denote files which should be sent as part of the request body. If files are present in PARAMETERS, the content type of the request is always `multipart/form-data'. If the value is a list, the part of the list behind the first element is treated as a plist which can be used to specify a content type and/or a filename for the file, i.e. such a value could look like, e.g., (#p"/tmp/my_file.doc" :content-type "application/msword" :filename "upload.doc"). URL-ENCODER specifies a custom URL encoder function which will be used by drakma to URL-encode parameter names and values. It needs to be a function of one argument. The argument is the string to encode, the return value must be the URL-encoded string. This can be used if specific encoding rules are required. CONTENT, if not NIL, is used as the request body - PARAMETERS is ignored in this case. CONTENT can be a string, a sequence of octets, a pathname, an open binary input stream, or a function designator. If CONTENT is a sequence, it will be directly sent to the server (using EXTERNAL-FORMAT-OUT in the case of strings). If CONTENT is a pathname, the binary contents of the corresponding file will be sent to the server. If CONTENT is a stream, everything that can be read from the stream until EOF will be sent to the server. If CONTENT is a function designator, the corresponding function will be called with one argument, the stream to the server, to which it should send data. Finally, CONTENT can also be the keyword :CONTINUATION in which case HTTP-REQUEST returns only one value - a `continuation' function. This function has one required argument and one optional argument. The first argument will be interpreted like CONTENT above (but it cannot be a keyword), i.e. it will be sent to the server according to its type. If the second argument is true, the continuation function can be called again to send more content, if it is NIL the continuation function returns what HTTP-REQUEST would have returned. If CONTENT is a sequence, Drakma will use LENGTH to determine its length and will use the result for the `Content-Length' header sent to the server. You can overwrite this with the CONTENT-LENGTH parameter (a non-negative integer) which you can also use for the cases where Drakma can't or won't determine the content length itself. You can also explicitly provide a CONTENT-LENGTH argument of NIL which will imply that no `Content-Length' header will be sent in any case. If no `Content-Length' header is sent, Drakma will use chunked encoding to send the content body. Note that this will not work with older web servers. Providing a true CONTENT-LENGTH argument which is not a non-negative integer means that Drakma /must/ build the request body in RAM and compute the content length even if it would have otherwise used chunked encoding, for example in the case of file uploads. CONTENT-TYPE is the corresponding `Content-Type' header to be sent and will be ignored unless CONTENT is provided as well. Note that a query already contained in URI will always be sent with the request line anyway in addition to other parameters sent by Drakma. COOKIE-JAR is a cookie jar containing cookies which will potentially be sent to the server (if the domain matches, if they haven't expired, etc.) - this cookie jar will be modified according to the `Set-Cookie' header(s) sent back by the server. BASIC-AUTHORIZATION, if not NIL, should be a list of two strings (username and password) which will be sent to the server for basic authorization. USER-AGENT, if not NIL, denotes which `User-Agent' header will be sent with the request. It can be one of the keywords :DRAKMA, :FIREFOX, :EXPLORER, :OPERA, or :SAFARI which denote the current version of Drakma or, in the latter four cases, a fixed string corresponding to a more or less recent (as of August 2006) version of the corresponding browser. Or it can be a string which is used directly. ACCEPT, if not NIL, specifies the contents of the `Accept' header sent. RANGE optionally specifies a subrange of the resource to be requested. It must be specified as a list of two integers which indicate the start and (inclusive) end offset of the requested range, in bytes (i.e. octets). If PROXY is not NIL, it should be a string denoting a proxy server through which the request should be sent. Or it can be a list of two values - a string denoting the proxy server and an integer denoting the port to use (which will default to 80 otherwise). PROXY-BASIC-AUTHORIZATION is used like BASIC-AUTHORIZATION, but for the proxy, and only if PROXY is true. If REAL-HOST is not NIL, request is sent to the denoted host instead of the URI host. When specified, REAL-HOST supersedes PROXY. ADDITIONAL-HEADERS is a name/value alist of additional HTTP headers which should be sent with the request. Unlike in PARAMETERS, the cdrs can not only be strings but also designators for unary functions (which should in turn return a string) in which case the function is called each time the header is written. If REDIRECT is not NIL, it must be a non-negative integer or T. If REDIRECT is true, Drakma will follow redirects (return codes 301, 302, 303, or 307) unless REDIRECT is 0. If REDIRECT is an integer, it will be decreased by 1 with each redirect. Furthermore, if AUTO-REFERER is true when following redirects, Drakma will populate the `Referer' header with the URI that triggered the redirection, overwriting an existing `Referer' header (in ADDITIONAL-HEADERS) if necessary. If KEEP-ALIVE is T, the server will be asked to keep the connection alive, i.e. not to close it after the reply has been sent. (Note that this not necessary if both the client and the server use HTTP 1.1.) If CLOSE is T, the server is explicitly asked to close the connection after the reply has been sent. KEEP-ALIVE and CLOSE are obviously mutually exclusive. If the message body sent by the server has a text content type, Drakma will try to return it as a Lisp string. It'll first check if the `Content-Type' header denotes an encoding to be used, or otherwise it will use the EXTERNAL-FORMAT-IN argument. The body is decoded using FLEXI-STREAMS. If FLEXI-STREAMS doesn't know the external format, the body is returned as an array of octets. If the body is empty, Drakma will return NIL. If the message body doesn't have a text content type or if FORCE-BINARY is true, the body is always returned as an array of octets. If WANT-STREAM is true, the message body is NOT read and instead the (open) socket stream is returned as the first return value. If the sixth value of HTTP-REQUEST is true, the stream should be closed (and not be re-used) after the body has been read. The stream returned is a flexi stream (see with a chunked stream (see as its underlying stream. If you want to read binary data from this stream, read from the underlying stream which you can get with FLEXI-STREAM-STREAM. Drakma will usually create a new socket connection for each HTTP request. However, you can use the STREAM argument to provide an open socket stream which should be re-used. STREAM MUST be a stream returned by a previous invocation of HTTP-REQUEST where the sixth return value wasn't true. Obviously, it must also be connected to the correct server and at the right position (i.e. the message body, if any, must have been read). Drakma will NEVER attach SSL to a stream provided as the STREAM argument. CONNECTION-TIMEOUT is the time (in seconds) Drakma will wait until it considers an attempt to connect to a server as a failure. It is supported only on some platforms (currently abcl, clisp, LispWorks, mcl, openmcl and sbcl). READ-TIMEOUT and WRITE-TIMEOUT are the read and write timeouts (in seconds) for the socket stream to the server. All three timeout arguments can also be NIL (meaning no timeout), and they don't apply if an existing stream is re-used. READ-TIMEOUT argument is only available for LispWorks, WRITE-TIMEOUT is only available for LispWorks 5.0 or higher. DEADLINE, a time in the future, specifies the time until which the request should be finished. The deadline is specified in internal time units. If the server fails to respond until that time, a COMMUNICATION-DEADLINE-EXPIRED condition is signalled. DEADLINE is only available on CCL 1.2 and later. If PRESERVE-URI is not NIL, the given URI will not be processed. This means that the URI will be sent as-is to the remote server and it is the responsibility of the client to make sure that all parameters are encoded properly. Note that if this parameter is given, and the request is not a POST with a content-type of `multipart/form-data', PARAMETERS will not be used.


Try to match TARGET-STRING between START and END against REGEX and replace all matches with REPLACEMENT. Two values are returned; the modified string, and T if REGEX matched or NIL otherwise. REPLACEMENT can be a string which may contain the special substrings "\&" for the whole match, "\`" for the part of TARGET-STRING before the match, "\'" for the part of TARGET-STRING after the match, "\N" or "\{N}" for the Nth register where N is a positive integer. REPLACEMENT can also be a function designator in which case the match will be replaced with the result of calling the function designated by REPLACEMENT with the arguments TARGET-STRING, START, END, MATCH-START, MATCH-END, REG-STARTS, and REG-ENDS. (REG-STARTS and REG-ENDS are arrays holding the start and end positions of matched registers or NIL - the meaning of the other arguments should be obvious.) Finally, REPLACEMENT can be a list where each element is a string, one of the symbols :MATCH, :BEFORE-MATCH, or :AFTER-MATCH - corresponding to "\&", "\`", and "\'" above -, an integer N - representing register (1+ N) -, or a function designator. If PRESERVE-CASE is true, the replacement will try to preserve the case (all upper case, all lower case, or capitalized) of the match. The result will always be a fresh string, even if REGEX doesn't match. ELEMENT-TYPE is the element type of the resulting string.


Matches REGEX against TARGET-STRING as often as possible and returns a list of the substrings between the matches. If WITH-REGISTERS-P is true, substrings corresponding to matched registers are inserted into the list as well. If OMIT-UNMATCHED-P is true, unmatched registers will simply be left out, otherwise they will show up as NIL. LIMIT limits the number of elements returned - registers aren't counted. If LIMIT is NIL (or 0 which is equivalent), trailing empty strings are removed from the result list. If REGEX matches an empty string the scan is continued one position behind this match. If SHAREDP is true, the substrings may share structure with TARGET-STRING.









Converts a terse declaration form into the corresponding object and validation handler.


Shortcut for displaying a formlet. It outputs the formlet HTML to standard-out (with indenting). If this is the last submitted formlet in session, display field values and errors, then clear out the formlet-related session information.



Returns HTML as a string, as well as printing to standard-out













Searches TARGET-STRING from START to END and tries to match REGEX. On success returns four values - the start of the match, the end of the match, and two arrays denoting the beginnings and ends of register matches. On failure returns NIL. REGEX can be a string which will be parsed according to Perl syntax, a parse tree, or a pre-compiled scanner created by CREATE-SCANNER. TARGET-STRING will be coerced to a simple string if it isn't one already. The REAL-START-POS parameter should be ignored - it exists only for internal purposes.








































This class is specifically for fields that return multiple values from the user


This class is for fields that show the user a list of options