Form Module

1. Goals

In the Magnolia samples, as well as in the Sitedesigner, we provide the possibility to create dynamic forms which then send an email when the form is posted. We want to improve this and make it available for more generic use cases.

• generic reusable dynamic forms
• processing of the input can be changed (email, csv, ..)
• validation

1.1 Boundary

This form module is not necessarily able to be used together with other frameworks like Spring, ... It is mainly used for contact forms or basic order forms.

2. General Improvements

The improvements must be seen in the context of the current samples form.

• control names Each control can have a name. The author can give each control a name which is then used as the name for the control (parameter).
• form paragraph The form is a paragraph instead of a page template. This allows a more flexible usage.
• validation a 'simple' client side validation should be possible
• validation messages the processor can exposing validation errors (server side validation)
• post to any url The url (if not the same page) can be defined.
• request processor a request processor is defined in the paragraph config (not the dialog!). This allows the usage of the form module for many other usecases in a simple way (provided processors are email, csv log)
• reuse values if the processor is not successful (validation) the fields contain the posted values

3. Request processors

3.1 Mail

By default the form sends an email with listing the parameters as they are defined in form (like what we do in the samples for the moment). In addition an can:

• email templates Now that the controls have names the author can define a mail template by using the names (freemarker)
• confirmation mail In addition to sending a email to the site owner you can also send an confirmation email to the user who filled out the form
• reply-to address the reply to address is not necessarily the address of the sender.

3.2 CSV

The posted forms should be logged in a csv formatted file.

4. Validation

In the config of the module one can register validators (patterns). A view are provided:

• required (not empty)
• number
• email
• url

The user can select on of the validators in the paragraph dialog

4.1 Client Side

A basic js library must be found and used.

4.2 Server Side

This is up to the processor.

4.3 Avoiding Spam

We might use a Catcha, Honeypot or similar as planned to be part of the ME. In any case, we need to have some server side checking so that a flooding of request processors can be avoided (at least, avoid that someone can flood the mail server or DB by turning off client-side validation JS.)

Ideally both kind of validation use the same framework. We should check out: http://oval.sourceforge.net