Code

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#10781 closed (invalid)

Wrong way to style forms demonstrated in docs

Reported by: boxed Owned by: nobody
Component: Documentation Version: master
Severity: Keywords:
Cc: boxed@… Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

The docs has the following example:

<form action="/contact/" method="POST">
    {% for field in form.visible_fields %}
        <div class="fieldWrapper">

            {# Include the hidden fields in the form #}
            {% if forloop.first %}
                {% for hidden in form.hidden_fields %}
                {{ hidden }}
                {% endfor %}
            {% endif %}

            {{ field.errors }}
            {{ field.label_tag }}: {{ field }}
        </div>
    {% endfor %}
    <p><input type="submit" value="Send message" /></p>
</form>

This has the nasty side effect of not printing out the hidden variables if there are no non-hidden variables, in addition to making the code needlessly complex. This should be changed to:

<form action="/contact/" method="POST">
    {% for field in form.visible_fields %}
        <div class="fieldWrapper">
            {{ field.errors }}
            {{ field.label_tag }}: {{ field }}
        </div>
    {% endfor %}
    {# Include the hidden fields in the form #}
    {% for hidden in form.hidden_fields %}
        {{ hidden }}
    {% endfor %}

    <p><input type="submit" value="Send message" /></p>
</form>

Attachments (0)

Change History (3)

comment:1 Changed 5 years ago by boxed

  • Cc boxed@… added
  • Has patch set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Version changed from 1.0 to SVN

comment:2 Changed 5 years ago by mtredinnick

  • Resolution set to invalid
  • Status changed from new to closed

The documentation includes example code for the common cases. If you're doing something unusual, such as a form with no visible variables, then, yes, you'll need to make adjustments. At that level, it's reasonable to expect the developer to know what they're doing. We cannot cover every possible use of features in the example code and it's more important to provide clues for those who are going to need them and not provide incorrect examples.

Your proposed change would be incorrect, as it creates an invalid HTML form: form elements cannot contain input elements directly, the latter must be inside a block element (e.g. the div). That is why it's constructed the way it is.

comment:3 Changed 5 years ago by boxed

Invalid HTML because an invisible input element is not inside a div? Now you're just jerking my chain. The proposed change would make the code smaller, easier to read, cover all cases instead of just a subset and be perfectly valid HTML.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.