Add a basic skeleton for Wagtail form builder
Add form builder and the basic form workflow

also add the implementation of all form field types. The form will save
the submitted data to the database (using the FormSubmission) model.
Add generic send_email task in wagtailadmin.tasks

This will be used from the send form data to email. It has been added to
the wagtailadmin.tasks module to use celery if it has been defined and
configured or just send the email if not (just like the
send_notification task).
Add first version of send form data to email

This has been added in a generic way to allow defining form processing
backends. Sending the form data to an email is one of these backends -
others may include for instance call a web service with the form data (for
instance in a customer complains form we'd need to start a customer
complains workflow).

In any case, if the AbstractForm has a 'form_processing_backend'
attribute which should be a class, a new object of that class will be
generated and its process method will be called. The process method needs
two argumetns: The Page to pass any needed paramaters and the form to
actually pass the form data.

The form processing backends should inherit from the BaseFormProcessor
class (however probably this will be refactored to just use duck-typing
since I don't think that a base class offers anything here) and implement
the process method. Also, another useful method would be the
validate_usage to be called from the Form that uses the backend and
actually check that the form defines the correct fields - an example is
that for the email processor we need to define an email_to field in the
form. The validate_usage would need to raise an ImproperlyConfigured
exception if it has not been configured yet, however it has not been yet
implemented.
Make from_address optional in send_email_task
Add metaclass for AbstractForm and validate ...

FormEmailProcessor.

The metaclass is used to add each non-abstract form in a registry in a
similar way as for Pages. It also checks if an form_processing_backend is
defined and if it is it will call its validate_usage method. This way, the
validate_usage method can throw immediately and ImproperlyConfigured
method so the developer would know if he's done something wrong.

The validate_usage method of the FormEmailProcessor has been implemented
this way.
Add a basic views skeleton for wagtailforms
Add basic form submission views

Add two urls: index which lists all different forms that have been defined
and submissions which for a specific form will list all its submissions.

The index lists each Page seperately (so if we have two different
instances of a form they will be listed seperately here), so the
submissions view will need the app_label, model_name and id to find out
all the submissions of a specific page.
Change pagination_nav.html to work without linkurl

pagination_nav.html received a linkurl parameter which has to be a url
name that get resolved to generate the link for next/previous. The thing
is that if the url to be resolved had parameters, these wouldn't be passed
and an exception would be thrown when trying to resolve it. A quick and
dirty fix is to just use {% url linkurl as link_to_use %} so link_to_use
will be empty and the currrent page url will be used.
Add pagination to form submissions view
Add submit date from/to filter for form submission
Integrate wagtailforms to wagtailadmin_nav
Add requirements to setup.py

New requirements: Unidecode to help into converting unicode text to slugs
(also used in img-proc-backends). unicodecsv to extract UTF-8 CSVs.
Add export to CSV support for form submissions and

convert form submissions to have a generic relation with the specific Form
for which they were created instead of a Page.
Add a dummy_request method to Page so that we can generate page previews without passing in the active request object (which may have undesirable side effects, e.g. may be a POST)
Fix code for pep8 compatibility
Add get_page_modes and show_as_mode methods to Page.

This abstracts out from the preview methods the details of how the page is generated.
Support within wagtailadmin for selecting a view mode in which to preview a page.

The 'preview' option is split out from the 'save' popup menu into its own button (it was deemed appropriate to split it off since it doesn't perform any database-level actions). If the page defines multiple page modes in get_page_modes, this button becomes a popup, allowing the editor to choose a mode. Finally, preview_on_create and preview_on_edit are updated to pass the chosen mode into the page's show_as_mode method.
preview buttons (and dropdowns generally) improve a little
ensuring classes are consistent