This means that we can use its absence as an indication that front-end requests are being made by a non-logged-in user and are thus safe to cache (i.e. don't include the editor toolbar).
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 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.
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.
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.
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).
