All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Form Wizard for TYPO3 4.2

From TYPO3Wiki
Jump to: navigation, search
This page belongs to the Core Team (category Core Team)

New Form Wizard project for TYPO3 4.3


The current FORM Content Object is pretty old and a bit outdated. Although a lot can be done with the Typoscript of the FORM cObject, the cObject itself is quite simple and not very configurable. It's also not very user friendly. More and more customers like to build sophisticated forms by themselves and don't have the knowledge to do this by Typoscript. Therefor we need a new Form Wizard which has more possibilities and is more user friendly. Also the possibilities of the currently available Typoscript can be improved.

Below are my thoughts and ideas and some of them could be unclear to you. If you have any questions, remarks or other things you would like to share, please e-mail me or add it to this page.

This document is far from being finished :-)


  • Easy forms are simple to implement by filling the textarea with
  • Label | [* = required] [Fieldname =] type of form element
  • Validation is easy for required- or emailfields
  • It is possible to validate with regular expressions (not many people know this)
  • Simple wizard to configure the form
  • Usable for search or login form as well


  • Data can't be stored
  • Wizard does not show all possible configuration options
  • Validation is hard when using regular expressions (did an editor ever use this, don't think so)
  • Validation can only be done when the whole form is submitted
  • Javascript alert box when data is validated wrong, no server side validation
  • Predefined e-mail output for plain text and HTML e-mails
  • No configurable templates for plain text and HTML e-mails and autoresponder
  • Layout option is very poor (For instance: You can't define if checkboxes need to be aligned horizontal or vertical within one form (Using TS)
  • No possibility to group questions for fieldsets
  • No possibility to divide the form in multiple pages
  • No confirmance check for the visitor
  • Elements can not be reused (it could be an advantage of having a repository like ICEpack)
  • Combination of CSS and XHTML is hard (No preconfigurable form layouts to choose from)
  • Wizard does not show the original language in translations
  • Redirect can't be set in the textarea or wizard
  • No possibility to sent mail to different persons using filters or conditions.
  • It's not possible to insert other content between form elements unless you know HTML (Wizard or Textarea). This is also a security risk because of Cross Site Scripting.
  • No handling of file uploads
  • Accessibility is bad
  • Mail files (discussable)
  • Only the very basic form fields are available. There is no way to combine field types (especially important for storing)

Related extensions

The extension repository contains a lot, and I mean a lot, of mail and form extensions. Concluding from this there is a big demand for changing the wizard and cObj, but we already know that

Available form extensions

22.11.2006 Peter Luser

  • Advanced form-mailer (html template based forms), multipage forms, server side error checks, HTML AND Plaintextmails, advanced file upload functionality, "print" template.

drecomm formmaker (dre_formmaker) 23.01.2007 Bas Hoonhout @ Drecomm BV

  • Advanced form making extension to create forms over multiple pages with direct data processing, conditional adjustments, support for multiple instances of form fields, reusability of form parts and a diversity of options concerning final data processing.
  • Tmailform (pil_mailform) & Mailform Captcha extension (cr_tmailform_captcha) 05.01.2007 Tonni Aagesen Template-based mailform that aims to give the developer the highest amount of design flexibility.

  • Formbuilder (formbuilder) 13.06.2005 Jean-David Gadina A tool designed to help you create any kind of forms in a frontend context, associated with a backend module, for back-office purposes.

  • Ameos Formidable (ameos_formidable) 13.02.2007 Jerome Schneider Form-oriented API

  • Onqform (onqform) 02.05.2005 Edgar Pisani Forms Plugin

  • HTML Forms Toolkit (vjforms) and Mailform (with vjforms) (vjmailform) 18.05.2006 Vincent Tietz Provides a library with PHP-Classes for creating and rendering HTML Forms. With sophisticated PHP validation.

  • Qforms (qforms) 20.09.2006 Lars Quitsch - Agentur Barth An easy to use form editor

  • ABA Mail Form (abamailform) 24.04.2007 Silvio Spagnoli (Abaco Informatica) advanced form-mailer (html template based forms)

  • IceForms (iceforms) 12.05.2005 Sven Wilhelm A object-oriented form library with validation support. IMPORTANT - Do not use it for production extension yet.

  • PEAR::HTML_quickform (bb_htmlquickform) 10.10.2006 Bernhard Berger

  • IDAA FE Utilities (idaa_fe_utilities) 13.04.2007 Jrg Krner form-, template-, error- and db helpers

  • ft&rbos Form Creator (ft_rbo_form) 04.08.2006 Frank Tilchner & Rene Becker Generates Forms from TCA for Frontend

  • Powermail (powermail) 09.03.2008 Alexander Kellner, Mischa Heissmann Powerful and easy mailform extension with many features like IRRE, database storing (Excel and CSV export), different HTML templates, javascript validation, morestep forms, works with date2cal and static_info_tables and many more...

Extensions which offer similar functionality

  • Survey (survey)

  • Advanced Surveys (ms_survey)

  • Questionaire (pbsurvey)

  • Oxcs graphic survey (oxcs_graphic_survey)

Extensions which add extra functionality to the FORM cObject

  • Show form data before submit (nc_formresults) 14.09.2005 Rupert Germann for Netcreators Nederland Extends the "Form" content-element by the possibility to display a "confirm data" form before actually submitting any data.

  • Form Result (gst_formresult) 23.11.2005 Stefan Hafeneger There is no longer support available from me! If you want to develop this extension further please drop me a line. -- Displays the result of a submitted content form element and saves it in a database.

  • Mailform preview (julle_formpreview) 18.09.2006 Christian Jul Jensen Let users preview mailform content before actually sending it

  • Extended Mail Forms (gsi_mailform_ext) 23.09.2004 Martin Kutschker Enhances the mail form (and the wizard) with many small details.

  • File Upload (fileupload ) 05.01.2006 Mads Brunn A plugin to display an upload form to front end users. Checks mime types and extensions.

  • Differentiated form mail recipients (julle_diffformmailrcp) 07.01.2004 Christian Jul Jensen

  • Save Form Mail (pk_save_form_mail) 05.05.2003 pekue Saves data submitted via mailform to the database

  • Formmail to CSV (julle_form2csv) 18.09.2006 Christian Jul Jensen Saves formmails to CSV

  • Formmail recipients (julle_formreceipt) 11.01.2006 Christian Jul Jensen Sends a receipt to the submitter of a formmail

  • Mailform evaluation wizard extension (formevalwizard) 09.04.2006 Juraj Sulek Extend the standard MailForm Wizard to work with evaluation options. You can define your own evaluation types by user or group tsConfig so the user doesnt need to know regular expressions and he only need to choose the defined type by name.

  • Form Validation (modulis_fvalidate) 13.03.2006 Adrien Laurent

  • Accessible Form Validation (accessible_form_validation) 19.03.2007 Laurent Thireau Makes Typo3 standard mailform accessible via server check (no JavaScript)

  • VisionConnect SSL Forms (vc_sslforms) 08.02.2007 Michael Sprotte This extension puts pages which contain mailforms in an SSL-environment. Therefore a SSL-host with the same server (HTTP host name) name has to exists.


  • Frontend forms code library (frontendformslib) 17.10.2005 Robert Lemke

  • Datepicker tools
  • Captcha tools
  • Formbuilder (so_formbuilder) 06.03.2006 Onno Schuit Forms are a piece of cake now. Just set up your database-driven extension. Then make an html template, throw in the tablefield names as markers, and watch this extension spitting out your form!

  • SICI Forms (sici_forms) 06.06.2006 Davide Principi Allows the creation of downloadable and precompiled forms, starting from rtf or OpenOffice documents


Right now all the configuration of the FORM cObject is done by one single entryfield, which can be filled manually or with the Form Wizard. This can also be done in a different way. Possible ways are:

  • Single element with one input field which could be filled manually or with the Form Wizard. This is exactly how it is done now, only wizard and possibilities need to be extended.
  • Single element using Dynamic Flexforms so no textarea is present and data is stored as XML.
  • Single element which connects to multiple form elements (like pbsurvey)
  • IRRE based elements like ICEpack from JoH asenau. Almost the same as above.

Can we somehow use the FORM cObject to use it for other purposes as well. Right now it is possible to build search- or login forms with it as well. But that's just simply naming the fields right and possibly send it to another page-id. Can we take over the functionality of the Direct Mail Subscription extension or Frontend User Registration? (sr_feuser_register is complicated, but just a thought). In my opinion there should not only be a FORM cObj, but a complete form library.


  • It must still be possible to build a form only using Typoscript. Don't loose focus on that! (Nice warning to myself)
  • Don't work with HTML templates, but with CSS-styled-content.
  • Must be backwards compatible. Still use the old configuration as well, or use update tool when TYPO3 version is raised.

Where to find it

  • typo3 / sysext / cms / tslib / class.tslib_content.php
  • t3lib / class.t3lib_formmail.php

Personal opinion

I'm not in for doing it the old way, by using a single cObject and a wizard. It's too minimal. But ..., we've got a problem when changing to another method. The compatibility gets lost. And this sucks. The best way would be to insert predefined items in the Form cObject itself, so items can be re-used in other forms, or even complete formgroups can be re-used (With form groups we definitely need IRRE). Or we have to build some tool to convert the old values to the new principle. This is also better for storage of the submitted data by the visitor. Each field answer needs to have a single record in the database (good database design) and not in a serialized array, which I hate. The whole form is a record with related answers, like in pbsurvey. There needs to be a tool that can export these records to a csv file. We have to take care of a lot of possible options which can be used in forms. Not only the standard field types, but also radiobuttons combined with an open text field like “Other”, matrix questions, combinations of different field types, fields combined with images or explaining text, so this can be a big OO form library which must be available to front- and backend. A nice thing would be some kind of backend module to build the form more visually, showing the form how it will be rendered in the frontend (maybe other CSS, but close to it).

Helpfull stuff


Form library projects


  • “Defensive design for the web” by Matthew Linderman and Jason Fried. ISBN 0-7357-1410-X
  • External Packages, libraries etc
  • PhpLIB's OOP Forms,
  • Web Form Design - Filling the Blanks. ISBN 1-933820-25-X

Form Wizard

<snip> The new Form Wizard will be drag & drop based, so if you like to have an input field, you simply drag it into the form in the wizard. You can change the order of all the form items easily by dragging them to the right spot in the form wizard. When clicking on an item, the properties field will adapt where you can change the default configuration for an element.

A lot of new features will be introduced, like having fieldsets in fieldsets, something that is currently not available in the Form Wizard. Also a datepicker, more validation options and other stuff will be implemented. You can even add your own stylesheet to it in the backend, so the form will look exactly look how it will be displayed in the frontend, similar to htmlarea where you can use your own stylesheet as well.

But it's not only the Form Wizard which needs a facelift. Also the FORM cObject, which you are partly referring to. Database storage has nothing to do with the Form Wizard, but with the cObject. Validation will be done server side in the future.

I've looked at a lot of solutions to make the output as general and stylable as possible. Two solutions I've found where worth trying it and I've eventually decided to go for the solution published by Cameron Adams on Sitepoint [1] to make an ordered list in which all items reside. There is also a solution by The man in blue [2] to put each element within it's corresponding label tag, which makes the code even more cleaner, but that's not quite what the label is for and you always need the label tag.

So the styling can be completely done using CSS. This is currently also possible, but in a lesser way. <snip>


At the T3CON07 in Karlsruhe I presented a first prototype of the form wizard to Ingo Renner, Jens Hoffmann and some others. This prototype was only the idea how people could add items to the form (drag & drop), configure them (inline editing), sort the order of the items (drag & drop sortables), select items (just click on them), deleting and some other minor stuff. This was a working prototype with the described functionality, but was still stand-alone. No form could be saved or loaded from the database and no styling had been done.

We planned to have a form wizard in version 4.2 based on the current configuration of the forms, so no extra functionality would be added to the FORM cObj.

Because of some major projects at my work and my house, we had to postpone the whole project.

After the release of version 4.2 beta3, I picked up the development of the Form Wizard again and wrote down the ideas I have for it. Also for the FORM cObj which needs to be rewritten as well. Currently I'm rewriting the prototype with database saving and loading in my mind and try to make the Prototype (The JS library) methods smaller.

More to come.

What should it do!

  • Easy to build forms
  • Use drag and drop features for adding the form elements
  • Use sorting techniques using drag and drop to change the order of the elements. Perhaps give the possibility to change the order by presenting “up” and “down” buttons in the elements as well when you select them.
  • Context sensitive configuration of each element. When you select a form element, all special configuration should be visible and editable immediately in a part of the screen. Perhaps give the possibility to change the configuration of the element when clicking it and showing an edit button. This edit button will open a popup with the configuration
  • Inline editing of texts, like labels and legends. Click on the text, for instance a label, and edit it. Leaving (of focus or enter) means storing
  • Removing an element is clicking it, show a delete button, and click on it
  • Elements must be reusable for other forms. This means, all elements should be stored as separate records
  • The Form record should only contain the id's of the elements it contains and the form configuration
  • It must be possible to add your own elements by using your own extension without xclassing anything. Xclassing sucks.
  • All possible configuration should be available for each element
  • The markup should be very generic (taking the used javascript library into consideration) How do we cope with the frontend with this. We need some listing (
    1. ) for the drag and drop part. Do we need this also in the frontend? Should be configurable in FE, I think
  • Even in the backend the form should be stylable using your own stylesheet(s). Make some kind of class selector for the elements to add a CSS class to them, like the paragraph and text class selector in rteHtmlArea. This is configurable and so should the one of the form wizard.
  • BE-user must be able to add standard validation like integers, required, etc, validation by regexp or own methods which can be selected by dropdown(Checkboxes would be better, because of multiple validation methods). It should be possible to add your own validation techniques using TS. This will add an extra option to the dropdown. ADDED: No dropdown. Should be possible to add more than one validation method.
  • Use DOM and Javascript techniques intensively, without sacrificing speed. When we get to massive javascript files, forget it.
  • Backwards compatible. WHOUA. No way this is possible without leaving the old textarea in the element or write a huge update tool. Since we are storing each element in a separate record, this could be huge. But we have to build an update tool.
  • QUESTION: Should we store elements immediately when we add them to the form? This means a lot of Ajax, because elements will be moved, deleted etc. Pro, user doesn't have to store the elements, only the form. Con, lot of writing and reading from and to the server.
  • Use existing and good techniques like IRRE. Fieldsets will hold the elements or fieldsets itself, which will hold elements again. How does IRRE work when you add a content element which will use child records? Although that does not really mather, because we only need the form itself as content element.

What do I use?

  • Prototype / Scriptaculous. These Javascript libraries are contrib libraries of the core and offer all we need.
  • Form markup solution published by Cameron Adams on Sitepoint [3]

Form Markup

We've chosen for the markup described by Cameron Adams on Sitepoint. This is an example how it looks like:

<form action="example.php">  
		<legend>Contact Details</legend>  
				<label for="name">Name:</label>  
				<input id="name" name="name" class="text" type="text" />  
				<label for="email">Email address:</label>  
				<input id="email" name="email" class="text" type="text" />  
				<label for="phone">Telephone:</label>  
				<input id="phone" name="phone" class="text" type="text" />  

By using this kind of markup it allows you to have different styled forms only with CSS. Please read on in the article on Sitepoint [4]. It explains a lot about

  • Styling
  • Fieldsets in fieldsets (for instance for radiobuttons and checkboxes)
  • Required fields
  • Error messages

I've worked with this kind of markup quite some while, and IMHO it's a blessing.

(added by Francois 09:39, 18 March 2008 (CET))

IMO the reflection should start with the syntax and structure of the FORM definition. The current syntax is limited in its scope but has the advantage of being easy to write by hand. A more complicated syntax would allow for more possibilities and both the wizard and helper libraries could offset the added difficulty of generating a form "manually".

I have added my thoughts to a separate page.