Forms can be created by inserting a page and select the 'Form' option from the '[DRECOMM] FORM MAKER' part of the page type selection box. A form is just a container to built forms in and has the same characteristics as the SysFolder page type.

The only property that can be set on this level is the temporary storage type. The temporary storage handles the storage of data filled in by the end-user during all form actions that need a page reload, like navigation between pages. There are two types of temporary storage available: cookie and database. Using cookies will require cookies to be enabled on the client machine, but will spare your database server. The size of cookies is limited, this might be a problem for large forms. The advantage of the database type is that you are not depending on any client side settings, the database server load, however, might increase significant.

In order to enable users to put a certain form anywhere in a website, there is a content element named 'Form Maker form'. With this content element, which is available from the 'Insert plugin' list, you can select a form from the TYPO3 page tree and place it anywhere on the website.

Forms consist of pages. A form can contain one or more pages. There are two types of pages: regular form pages and output pages. Each regular form page represent a phisical page in the frontend. In the frontend, there is always just one page displayed at a time. You can navigate between different regular form pages using the navigation buttons (explained in the 'Fields' section below). An output page represent a file. Such a file can be used after a user completed a form to offer a download or to attach that file to an e-mail.

Templates

The layout of a page, no matter which type, is primarily determined by a HTML template. Such a HTML template consists of HTML code with group and column markers as often seen in TYPO3 extensions. Group markers encapsulate pieces of HTML that correspond to a certain form group. Column markers are anchors that determine where the content from a certain column is placed. For a page with three groups and one to three columns per group, a HTML template could look like this:

<table border=”0”>

<!--GROUP1-->

<tr>

<td>###COLUMN1###</td>

<td>###COLUMN2###</td>

<td>###COLUMN3###</td>

</tr>

<!--GROUP1-->

<!--GROUP2-->

<tr>

<td colspan=”3”>###COLUMN2###</td>

</tr>

<!--GROUP2-->

<!--GROUP3-->

<tr>

<td colspan=”2”>###COLUMN1###</td>

<td>###COLUMN2###</td>

</tr>

<!--GROUP3-->

</table>

The first option when creating a form or output page enables users to upload a HTML template. Once an HTML template is uploaded, it can easily be editted using the 'File editor'. After finalizing the HTML template groups and columns need to be attached to the group and column markers in the template. This can be done with the 'Template settings'-wizard. This wizard will first try to match the markers found in the template with the created form tree in the TYPO3 page tree, for most users saving these autogenerated settings will be sufficient. For more complex forms you can use this wizard to customize the attachment of groups and columns.

When group and/or column markers are inserted in the HTML template it's impossible to attach the corresponding groups and/or columns at the same time. In order to prevent the frontend to become a total mess during the insertion of a group and/or column markers in the HTML template, group markers that have unattached column markers left after rendering are skipped and will not appear in the frontend.

Default template

Since HTML templates have the disadvantage that they have to be modified after every modification of the form structure and most of the forms don't need the ultimate flexibility of a custom HTML template, you can also the default template. The default template is a virtual and dynamic template that is created based on the form structure. Any page that has no custom HTML template available will generate it's own default template using the group and column structure found in the TYPO3 page tree part of that specific page.

The advantage of the usage of the default template is that the HTML template adapts automatically to any modification of the form structure. Since there really is an HTML template with group and column markers created, also with the default template groups with unattached column markers will be skipped. So, groups with three columns, but only two content elements will not appear in the frontend.

Since all the generation and attaching of groups and columns to their corresponding markers in the default HTML template is automated, the 'Template settings'-wizard is not needed anymore in the way it is used with custom templates. With the default template, this wizard is used to style the default template using CSS (see the 'Template settings wizard' section below).

Regular form pages

A regular form page is created by using the page type 'Form page' from the '[DRECOMM] FORM MAKER' part of the page type selection box. Like mentioned in the previous section, the regular form page have the possibilty to upload a template or use the default template and set the corresponding settings. Furthermore, there is the possibility to attach javascripts from the 'Javascript repository'. Javascripts on page level can be attached to two events: onLoad and onSubmit which fires at page load and form submission, respectivally.

The last option of regular form pages is to define output. This is done by using the 'Ouput'-wizard. If there is any output defined, the output is generated when the page where the output is defined is submitted. Output appear in two forms: downloads and e-mails. Downloads are offered via a download popup at the client machine and e-mails are, as expected, e-mailed to a certain address with or without attachments. Downloads. e-mail templates and e-mail attachments can be static files, uploaded via the 'Output'-wizard or dynamic files in the form of output pages. For a more detailed description of the possibilities of generating output, see the 'Output wizard' section below.

Output pages

A output page is created by using the page type 'Form output' from the '[DRECOMM] FORM MAKER' part of the page type selection box. This page type has the same template options as the regular form pages. However, no javascripts can be attached to output pages since they are static. Also, no output can be defined for obvious reasons.

Since regular form pages are inserted into a webpage, which is expected to contain the necessary CSS definitions, no extra CSS definitions are needed. An output page, however, is a stand alone page. So, everything from the opening HTML tag until the closing HTML tag need to be included in the page itself. Therefore, there is an option implemented to upload a CSS file. This file is literally inserted into the generated HTML page. Once the file is uploaded, it can be edited using the 'Stylesheet editor'.

Since you probably don't want to offer end-users HTML pages only, the generated HTML can be converted to other document types. The current options are plain and pdf. Plain means no conversion takes place and pdf will result in a Adobe Acrobat PDF file. The type of conversion is set by a selectbox named 'Output type'.

Shortcuts

Form pages can be shortcutted by using the default TYPO3 page type 'Shortcut'. The shortcuts acts exactly the same as normal TYPO3 shortcuts. In the background the ID of the shortcut page is used to identify the shortcut. Two shortcuts to the same page will result in two different pages. However, the content on a shortcutted page is identified by it's own ID. This means that in the example of the two shortcuts to the same page, the fields on both pages are actually the same.

Pages consist of groups. A group is created by using the page type 'Form group' from the '[DRECOMM] FORM MAKER' part of the page type selection box. Groups have multiple purposes. First, it is a container for the actual form fields. Using such a container makes it easy to shortcut and therefore reuse groups of fields. You could create a group 'Personal information' with name and address fields and shortcut to that group from several forms. Second, a group has pretty much the function of a row. Especially when using the default template a group corresponds with a TR tag, but also when using custom HTML templates you will see this is often the case. The last purpose of using groups is to make it possible to adapt the form dynamically depending on certain events or data. The adaption of the form can occur without a page refresh using javascripts attached to one or more fields or with a page refresh using conditions.

Groups consist of columns. Where a group itself can be seen as a row, the columns represent the columns in that row. The number of columns in a group can be defined by the first option when creating a group.

The second option gives  the opportunity to attach a condition to a group. The condition is evaluated and the group is only shown when the result of the condition is true (that is true in case of a boolean result, greater than zero in case of a numeric result and with a length greater than zero in case of a string). Conditions are created using the 'Condition'-wizard.

Furthermore, there are two checkboxes to set for each group. The 'Display by default' checkbox determines if a groups has to be displayed on page load. Every valid group is rendered, however when this checkbox is not checked, the group is not displayed due to the CSS setting 'display' is set to 'none'. This way, you can hide a group and let it appear when a checkbox is checked, for example, using javascripts (subform). The second checkbox is only relevant when the page where the group is a part of uses the default template. De default template generates a table, checking this checkbox will close the generated table and immidiately start a new one, before rendering this group and the groups after this group. This way, columns can be seperated for certain parts of a page.

Groups in groups

Groups can contain other groups. A group that contains other groups has simplified functionalities and is primarily meant to collect other groups. For example, a group cannot contain form fields and groups at the same time (it is phisically possible, but the form fields are ignored in such case). So, groups that contain other groups are meant to make reusing form parts more efficient, to simplify dynamic adaptation of forms due to javascripts or conditions.

The group in group principle is primarily meant to use with the default template. However, it is possible to use it with custom templates by nesting group tags in the template. Nevertheless, attaching fields and groups to their corresponding markers will become quite complex using the 'Template settings'-wizard.

Shortcuts

Form groups can be shortcutted by using the default TYPO3 page type 'Shortcut'. The shortcuts acts exactly the same as normal TYPO3 shortcuts. In the background the ID of the shortcut page is used to identify the shortcut. Two shortcuts to the same group will result in two different groups. However, the content in a shortcutted group is identified by it's own ID. This means that in the example of the two shortcuts to the same group, the fields in both groups are actually the same.

Groups are divided in columns. Only when using the default template columns actually have to correspond to columns in the frontend. Th default template is created based on this information, which is defined at group level. When using custom templates a column corresponds to a column marker, which doesn't necessarily have to correspond to a real column.

In order to prevent the frontend being messed up when modifying a template (default or custom), each column defined has to contain content. The content can be empty, but there has to be some content. If there is an empty column found, the whole group is skipped. This way, you could create a custom template with, say, twenty groups and only use ten of them. The ten groups that are not used are skipped, when you need to add a group in the form tree you will not need to modify the template immidiately.

Fields are the actual form content. Fields are placed in columns, this means that fields have actually to be put in one of the Form Maker columns defined by the group they are in. A field is created by creating a content element and select 'Form Maker field' from the list after selecting 'Insert plugin' as content type.

First you have to define a fieldtype via a selectbox. This selectbox is filled with all field types from the 'Fieldtype repository'. After selecting the fieldtype, you need to save the content element. Now, there are four wizards available to modify the appearance and functionality of the field: 'Fieldtype settings'-wizard, 'Input'-wizard, 'Condition'-wizard and 'Javascript'-wizard.

The fieldtypes defined in the 'Fieldtype repository' can contain variables, also known as user parameters, to be set per field using a specific fieldtype. Via the 'Fieldtype settings'-wizard you can set these variables.

Normally, the content of a field is set by the end-user. However, you might want to set the content yourself and even want to set the content based on other content. Therefore, the 'Input'-wizard exists. This wizard is actually a slightly modified 'Condition'-wizard. It also generates a PHP expression, but doesn't evaluate in true or false but in some value which is used as content for the field.

The 'Condition'-wizard works in the same way as it does for groups: the field is not rendered if the condition evaluates as false. This means the field will not exist and any references to it will break!

The 'Javascript'-wizard makes it possible to attach javascripts from the 'Javascript repository' to a field. The wizard has an interface to attach different javascripts to different events with ditfferent parameters. This wizard can be extended using presets, so event the most complex javascripts can be made user friendly.

Instances

Fields can exist in multiple instances. This is a very useful concept, but might be difficult to understand. An instance of a field is a different appearance of that same field. So, it's not another field and therefore it is impossible to get multiple instances of the same field appear in the frontend at the same time. When you create an instance of a field, you will get two content elements in the backend that is actually one field!

Confused? Compare it with yourself in your lazy afternoon clothes and in some expensive gala outfit. No matter which clothes you wear, you will not become someone else and you cannot wear both type of clothes at the same time (actually you could, but something would be wrong), so we now have two instances of you! Both instances look different and they even might act differently, but they both are you.

To create an instance, you copy a field and attach the original field to the property 'Instance of' of the copy. So, a field is an instance as soon it has the property 'Instance of' set or if the field appear in the property 'Instance of' of another content element. The whole procedure of copying and linking is automated via the 'Instance'-wizard which is accessible via the button next to the 'Instance of' field. This wizard has no interface, activating the wizard will copy the object, link the new object to the original and open the property window of the new object.

When you have multiple instances of a field, the conditions of these instances decide which of the instances is used. In the order they appear in the backend, the conditions of the instances are evaluated and the first instance evaluating as true will be used.

Once an instance is created you can modify it's properties independent from the original object. You probably have to change the conditions, but you could also change the fieldtype, for example. This way, you can show a field as open textbox or selectbox depending on the posted data.

Buttons

When you create a form with multiple pages, you need to enable end-users to navigate between the pages. This is done using buttons. Like fields, buttons are content elements that can be placed in a column. Creating a button is like creating a field, but instead of choosing 'Form Maker field' you choose 'Form Maker button'.

There are two types of buttons, 'button' and 'image', that correspond to the HTML input types 'submit' and 'image'. Furthermore, a button needs to have a value which is only relevant for buttons of the type 'button' but also required for buttons of the type 'image'. If choosing the type 'image', an image can be uploaded using the property 'image' and the dimensions can be set using the 'width' and 'height' properties.

A button needs an action. An action is selected by the selectbox 'Action'. The available actions are explained in the following table:

Text and HTML content

It is possible to add deafult TYPO3 content elements into your form, for example labels, titles and help texts. However, adding default TYPO3 content elements is restricted to the content types 'Text' and 'HTML'. This content also needs to be placed in one of the Form Maker columns of the group it is placed in.

Shortcuts

Also form content (fields, buttons and default TYPO3 content) can be shortcutted by using the default TYPO3 content element 'Insert records'. The shortcuts acts exactly the same as normal TYPO3 shortcuts. In the background the ID of the shortcut element is used to identify the shortcut. Two shortcuts to the same element will result in two different elements.

The 'File editor' is a simple editor to edit uploaded files. It often happens that templates and stylesheets that are uploaded need a slight modification. In order to prevent you need to upload the files over and over again while expirimenting or debugging with a template or stylesheet, the upload options of plain text files have the 'File editor'-wizard attached.

Once you opened the editor, the content of the uploaded file is shown in a text area and can be editted. Clicking the save button will save the file and return to the editted object. Clicking the close button will discard the changes made.

The 'Instance'-wizard is a wizard without interface for form fields. It copies the editted field and links the original field to the copied field by the 'Instance of' property of the copied field. This way, an instance is created. The new instance is opened for editting. See the 'instances' section for an explanation about why and how to use instances.

The 'Mass modifier'-wizard enables users to change a specific property for all objects on a page. For example, you can set the fieldtype of all fields on a page at once. This way, when you want to create a confirmation page you could copy the form groups of the actual form pages to another page and set all fieldtypes on that page to a static type, thereby changing all input boxes to static text boxes. You could also set all columns of all groups to a certain amount using this wizard.