Presto Content Management System
The Form Interface

<- ->

Documentation > Presto Developer's Manual > Under The Hood

The Presto Forms Interface enables HTML forms to be created and maintained through the Presto backend. Every form has an item in the backend of type "form", and under this are items of type "field". Together these define a form's input fields, actions, validation javascript, source of data (if any), and action to take with the data, including database update, log, and mailto functionality. It minimises the need to write HTML and Cold Fusion form scripts directly.

The module mainly consists of 6 tags that are used to present forms and process their entries in both front end websites and in the Presto backend administration interface.  Interestingly, almost all forms used in the Presto backend administration interface are created and managed by Presto itself!

These tags are usually referenced using <cfmodule>, e.g.

<cfmodule template="presto/tags/form/form_structure.cfm" form_id="97">

The form builder can be used to build and manage forms through the admin back-end and then serve those forms on the public site. It is very good for building the basic kinds of forms that we need to do over and over. Mostly these are forms that collect a number of fields of information, write those fields to a database table or log file, show some kind of thank you message, and optionally send an e-mail to the user or to a site admin. The form builder allows an Administrator to define the fields and their data validation rules.

The form can then optionally be linked to a table in the Presto! Database, so that one or more fields in the form can send/receive content to/from corresponding fields in the table (not all the form or table's fields need be connected though).  Currently the construction of the table is a manual process which is separate from the construction of the form.

Additionally, the form can be linked to an email template in Presto. Doing so indicates that the email is sent when the form is successfully submitted. The body of the email can include placeholders, which are replaced with the values submitted in the form.

Because the form builder is a general form building and serving tool, it is not without its limitations when it comes to very specific (custom) requirements. Therefore, it is not the ideal tool for all forms. Certain forms will still need to be built the old way in HTML and a handler script will need to be written from scratch.

Additionally, and perhaps most importantly, forms built in the form builder can be published to an HTML file which can then be further manipulated in ways that the general-purpose Form Builder does not support (i.e. specific layouts, complex data validation rules, multi-page forms, etc.) This will mostly be a manual process: capturing the form HTML generated when the dynamic form is served, creating an HTML file for that form, setting Presto to use the HTML form rather than the dynamic form, etc.  This is documented here.

<- ->

Valid XHTML 1.0!