.. _`crispy tag forms`: =========================== {% crispy %} tag with forms =========================== django-crispy-forms implements a class called ``FormHelper`` that defines the form rendering behavior. Helpers give you a way to control form attributes and its layout, doing this in a programmatic way using Python. This way you write as little HTML as possible, and all your logic stays in the forms and views files. Fundamentals ~~~~~~~~~~~~ For the rest of this document we will use the following example form for showing how to use a helper. This form is in charge of gathering some user information:: class ExampleForm(forms.Form): like_website = forms.TypedChoiceField( label = "Do you like this website?", choices = ((1, "Yes"), (0, "No")), coerce = lambda x: bool(int(x)), widget = forms.RadioSelect, initial = '1', required = True, ) favorite_food = forms.CharField( label = "What is your favorite food?", max_length = 80, required = True, ) favorite_color = forms.CharField( label = "What is your favorite color?", max_length = 80, required = True, ) favorite_number = forms.IntegerField( label = "Favorite number", required = False, ) notes = forms.CharField( label = "Additional notes or feedback", required = False, ) Let's see how helpers works step by step, with some examples explained. First you will need to import ``FormHelper``:: from crispy_forms.helper import FormHelper Your helper can be a class level variable or an instance level variable, if you don't know what this means you might want to read the article "`Be careful how you use static variables in forms`_". As a rule of thumb, if you are not going to manipulate a `FormHelper` in your code, like in a view, you should be using a static helper, otherwise you should be using an instance level helper. If you still don't understand the subtle differences between both, use an instance level helper, because you won't end up suffering side effects. As in the next steps I will show you how to manipulate the form helper, so we will create an instance level helper. This is how you would do it:: from crispy_forms.helper import FormHelper class ExampleForm(forms.Form): [...] def __init__(self, *args, **kwargs): super(ExampleForm, self).__init__(*args, **kwargs) self.helper = FormHelper() As you can see you need to call the base class constructor using ``super`` and override the constructor. This helper doesn't set any form attributes, so it's useless. Let's see how to set up some basic `FormHelper` attributes:: from crispy_forms.helper import FormHelper from crispy_forms.layout import Submit class ExampleForm(forms.Form): [...] def __init__(self, *args, **kwargs): super(ExampleForm, self).__init__(*args, **kwargs) self.helper = FormHelper() self.helper.form_id = 'id-exampleForm' self.helper.form_class = 'blueForms' self.helper.form_method = 'post' self.helper.form_action = 'submit_survey' self.helper.add_input(Submit('submit', 'Submit')) Note that we are importing a class called ``Submit`` that is a layout object. We will see what layout objects are in detail later on, for now on let's just say that this adds a submit button to our form, so people can send their survey. We've also done some helper magic. ``FormHelper`` has a list of attributes that can be set, that affect mainly form attributes. Our form will have as DOM id ``id-exampleForm``, it will have as DOM CSS class ``blueForms``, it will use http ``POST`` to send information and its action will be set to ``reverse(submit_survey)``. Let's see how to render the form in a template. Supposing we have the form in the template context as ``example_form``, we would render it doing:: {% load crispy_forms_tags %} {% crispy example_form example_form.helper %} Notice that the ``{% crispy %}`` tags expects two parameters: first the form variable and then the helper. In this case we use the ``FormHelper`` attached to the form, but you could also create a ``FormHelper`` instance and pass it as a context variable. Most of the time, you will want to use the helper attached. Note that if you name your ``FormHelper`` attribute ``helper`` you will only need to do:: {% crispy form %} This is exactly the html that you would get::
What you'll get is the form rendered as HTML with awesome bits. Specifically... * Opening and closing form tags, with id, class, action and method set as in the helper::
[...]
* Django's CSRF controls::
* Submit button::
.. _`Be careful how you use static variables in forms`: http://tothinkornottothink.com/post/7157151391/be-careful-how-you-use-static-variables-in-forms Manipulating a helper in a view ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Let's see how we could change any helper property in a view:: @login_required() def inbox(request, template_name): example_form = ExampleForm() redirect_url = request.GET.get('next') # Form handling logic [...] if redirect_url is not None: example_form.helper.form_action = reverse('submit_survey') + '?next=' + redirectUrl return render_to_response(template_name, {'example_form': example_form}, context_instance=RequestContext(request)) We are changing ``form_action`` helper property in case the view was called with a ``next`` GET parameter. Rendering several forms with helpers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Often we get asked: "How do you render two or more forms, with their respective helpers, using ``{% crispy %}`` tag, without having ``
`` tags rendered twice?" Easy, you need to set ``form_tag`` helper property to ``False`` in every helper:: self.helper.form_tag = False Then you will have to write a little of html code surrounding the forms:: {% crispy first_form %} {% crispy second_form %}
You can read a list of :ref:`helper attributes` and what they are for. Change '*' required fields ~~~~~~~~~~~~~~~~~~~~~~~~~~ If you don't like the use of ``*`` (asterisk) to denote required fields you have two options: * Asterisks have an ``asteriskField`` class set. So you can hide it using CSS rule:: .asteriskField { display: none; } * Override ``field.html`` template with a custom one. Make crispy-forms fail loud ~~~~~~~~~~~~~~~~~~~~~~~~~~~ By default when crispy-forms encounters errors, it fails silently, logs them and continues working if possible. A settings variable called ``CRISPY_FAIL_SILENTLY`` has been added so that you can control this behavior. If you want to raise exceptions instead of logging, telling you what’s going on when you are developing in debug mode, you can set it to:: CRISPY_FAIL_SILENTLY = not DEBUG Change crispy-forms default classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Django fields generate default classes, crispy-forms handles these and adds other classes for compatibility with CSS frameworks. For example a ``CharField`` generates an ``