Implementation of this module happens in two parts: 1) the HTML form, and 2) the processing page, containing the CustomForm module. Your HTML form's "action" must point to the processing page.
Your HTML Form
Forms submitted to this module MUST have a hidden field called "FormName". The value of this field identifies this form's setup in the database, so it must be unique for each form submitted to the module, and it should not change once the form is in use.
Fields that are to be inserted into the database must have a name in the format "[Type]_[FieldName]". Here's an example:
<form action="/myprocessingpage.cfm" method="post">
Pet's Name: <input type="text" name="text_PetsName" size="20" maxlength="255" >
Birthdate: <input type="text" name="date_BirthDate" size="10" maxlength="10" >
Number in your household:
<select name="number_NumberInHousehold" size="1">
<option value="4+">4 or more
Most embarrassing moment:
<textarea name="longtext_EmbarrassingMoment" rows="5" cols="20" ></textarea>
<input type="Submit" value="Submit">
<input type="hidden" name="FormName" value="PersonalInfo">
<input type="hidden" name="NotifyEmail" value="[email protected],[email protected]">
<input type="hidden" name="NotifySubject" value="New Personal Info form submitted">
Important notes about form validation:The "type" that you indicate in your form will direct the database to store the information in a particular format. If you allow users to submit data that isn't properly formatted, the data from that field won't be properly inserted in the database. A "raw" version of the form will be stored in the database, but it isn't very helpful in terms of reporting. Also, if you've designated a "NotifyEmail" address, the entire form submission will be included in your email notification. Here are specific notes about validating each type of field:
TextText fields can include any characters and be up to 255 characters long. Data validation is very simple, by setting the field's "maxlength" attribute to 255 as in the examples above.
LongTextLong text fields can be any length, which makes them well-suited to the "textarea" form field. Please note however, that if you plan to implement reporting of your form results, the LongText fields cannot be used to group, sort or filter your data.
The processing pageYour processing page can be located in any web-accessible path in your site and must end with the .cfm extension. The only other requirement is that it include the name of this module, "CustomForm". Here's a simple example:
Here's an example that ties the form submission to the "member" database. If your form has a field called "Email", this attribute inserts a special handler that checks to see if that email is already in the database. If it is, the new form submission is tied to that member data. If not, the user is first prompted to enter the personal/demographic data required to add them to the database. The "joindisplay" is actually a .cfm file located in the CustomDisplays containing the form that prompts the user for this data and formats it properly for the database. (Email [email protected] for more help with this feature.)
<cf_OnTheFly module="CustomForm" joindisplay="JoinForm">
Notification emailsEach form submission will be emailed to the email address(es) you specify using "NotifyEmail". You can use the NotifyEmail attribute in the CustomForm module on the processing page to have all notifications for all forms sent to the same address(es), or you can include a hidden NotifyEmail field in each form that's submitted to direct notifications for different forms to different addresses.
You can also optionally specify the "NotifySubject", which will control the subject of the email notifications. The default is "RESPONSE: [FormName]", where [FormName] is the value you specified in your hidden FormName field. In the form example above, the subject would be "New Personal Info form submitted". If that hidden field were taken out of the form, the subject would be "RESPONSE: PersonalInfo".