Default representation of a Form
Ivan Sagalaev
A new Form class' default representation (that is goes out of `print f`)
is an HTML table. For those who cares about that proverbial 'semantics'
thing this looks wrong. From the practical point of view it's also not
very convenient since it (for example) doesn't allow to layout the form
in different ways: labels above widgets, labels to the left of widgets,
labels and widgets in one string etc.
Instead I suggest this default representation:
<p id="p_fieldname">
<label for="id_fielname">Field name</label>
<input ... id="id_fieldname"/>
</p>
...
An ID on <p> is debatable. However from a recent experience of laying
out a site with forms designed in many different ways it helps immensely!
The thing that I'm not sure how to do is display of errors. I'm now
doing it with <em>:
<p>
<label/>
<input/>
<em class="error">...</em>
</p>
...
But something disturbs me about this way. I would be happy to see a
better proposal!
Thanks!
Adrian Holovaty
> A new Form class' default representation (that is goes out of `print f`)
> is an HTML table. For those who cares about that proverbial 'semantics'
> thing this looks wrong. From the practical point of view it's also not
> very convenient since it (for example) doesn't allow to layout the form
> in different ways: labels above widgets, labels to the left of widgets,
> labels and widgets in one string etc.
>
> Instead I suggest this default representation:
>
> <p id="p_fieldname">
> <label for="id_fielname">Field name</label>
> <input ... id="id_fieldname"/>
> </p>
> ...
Hey Ivan,
Good idea! I think we should definitely add Form.as_p() -- as we
currently have as_table() and as_ul(). As for which of those is used
by default, it doesn't really matter to me; I like the <table> output,
but I can definitely appreciate the argument for using <p>s instead.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Ivan Sagalaev
> I like the <table> output,
> but I can definitely appreciate the argument for using <p>s instead.
I would say not using tables for layout may count as a good practice
like encouraging clean URLs, proper distinction of GET and POST etc.
Brantley Harris
tables. But practical CSS just isn't there yet. Yes, tables aren't
good for general layout, but they still have their uses, and forms are
a prime example.
On 11/30/06, Ivan Sagalaev <Man...@softwaremaniacs.org> wrote:
Waylan Limberg
> Maybe good practice, but not practical. I'd love to not have to use
> tables. But practical CSS just isn't there yet. Yes, tables aren't
> good for general layout, but they still have their uses, and forms are
> a prime example.
>
could arguably be considered tabular data in many cases, so a table
could potentially be acceptable. That said, other alternatives certainly
need to be considered, and made available.
So count me +1 on adding Form.as_p()
I'm +0 on making it the default.
Ivan Sagalaev
> Maybe good practice, but not practical. I'd love to not have to use
> tables. But practical CSS just isn't there yet.
Many web sites prove otherwise though :-)
> Yes, tables aren't
> good for general layout, but they still have their uses, and forms are
> a prime example.
I agree that laying out a form with CSS is not a very clean thing. But
it does give you a way to change the layout with just CSS (like moving
labels to the left or to the top of a field). And with tables you can't
do it in practice.
Anyway we aren't fighting for the only one available method just for the
default. And since this preference is a controversial subject I think
this is the thing that should just be ruled by core team or we may argue
this to death :-)
Brantley Harris
would take care of all of this nonsense.
James Bennett
> it does give you a way to change the layout with just CSS (like moving
> labels to the left or to the top of a field). And with tables you can't
> do it in practice.
It can be a pain, but it doesn't have to be. For a while now, I've
been using definition lists to lay out forms (which is arguably an
acceptable use of them, depending on how you want to read the HTML
spec), and I've found that to be about the easiest thing -- the LABEL
element and associated text go into a DT, and the actual form element
goes into a DD.
This has the accidental benefit of degrading gracefully in non-CSS
browsers, since the common representation of a definition list in
those browsers works well for a form.
So maybe an as_dl() method needs to go in?
;)
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
Lakin Wecker
Lakin
Lachlan Cannon
> as_dl() gets a +1 from me. I've used definition lists for forms and
> prefer it over tables. :)
Maybe there needs to be an easy hook for people to specify their own way of
laying a form out. It seems the as_ methods are gonna keep growing and growing.
--
Lach
Personal: http://illuminosity.net/
Adrian Holovaty
> Lakin Wecker wrote:
> > as_dl() gets a +1 from me. I've used definition lists for forms and
> > prefer it over tables. :)
>
> Maybe there needs to be an easy hook for people to specify their own way of
> laying a form out. It seems the as_ methods are gonna keep growing and growing.
That already exists -- you can subclass the Form and add your own methods.
Adrian Holovaty
With as_dl(), how would error messages be displayed?
Adrian Holovaty
> is an HTML table. For those who cares about that proverbial 'semantics'
> thing this looks wrong. From the practical point of view it's also not
> very convenient since it (for example) doesn't allow to layout the form
> in different ways: labels above widgets, labels to the left of widgets,
> labels and widgets in one string etc.
>
> Instead I suggest this default representation:
>
> <p id="p_fieldname">
> <label for="id_fielname">Field name</label>
> <input ... id="id_fieldname"/>
> </p>
I've implemented Form.as_p() in [4178]. The differences between my
implementation and your proposal are that I didn't give the <p> an
"id" attribute, and the errors get displayed in a <p> above the <p>,
rather than after the field.
Waylan Limberg
`Form._html_output()`. Now, anyone can write there own `as_method()`
as a one-liner - with one minor problem...
On 12/7/06, Adrian Holovaty <holo...@gmail.com> wrote:
>
> On 12/1/06, James Bennett <ubern...@gmail.com> wrote:
> > So maybe an as_dl() method needs to go in?
>
> With as_dl(), how would error messages be displayed?
I was going to suggest
<dt>label</dt>
<dd>error<dd>
<dd>field<dd>
But looking at the code, the error string is passed in first
regardless of whether `errors_on_separate_row` or not. Perhaps
`_html_output()` should use the optional mapping key for string
substitution [1]. So, for example:
- 93 output.append(normal_row % ((bf_errors, label, bf)))
+ 93 output.append(normal_row % ({ 'error' :
bf_errors, 'label' : label, 'field' : bf}))
Then
as_dl(self):
return
self._html_output(u'<dt>%(label)s</dt>\n<dd>%(error)s</dd>\n
<dd>%(field)s</dd>', u'?????', '</dd>', False)
Hmm, not sure how the top_errors would display here. Maybe someone
else could enlighten us on that.
Anyway, by key mapping string substitution, that would greatly enhance
the flexibility IMHO. It would certainly make creating custom
`as_method()` functions easier/more flexible.
As an alternative, there is also Template strings [2], but key mapping
works fine and (I believe) was in python2.3 (or earlier) while
Template strings were introduced in python2.4.
[1]: http://www.python.org/doc/current/lib/typesseq-strings.html
[2]: http://docs.python.org/lib/node40.html
--
----
Waylan Limberg
way...@gmail.com
Adrian Holovaty
> But looking at the code, the error string is passed in first
> regardless of whether `errors_on_separate_row` or not. Perhaps
> `_html_output()` should use the optional mapping key for string
> substitution [1].
Hey, that's a really good suggestion! I've checked in the improvement in [4182].
As for how to display top_errors in as_dl() -- I don't have any great ideas.
Jesper Karsrud
How about not wrapping the labels and fields in anything at all? That's
what makes most sense to me. It makes it even easier to style the forms
using CSS, plus it's even more semantic than using lists (being
unordered or definition lists), paragraphs and definately tables. The
output would be plain and simple;
<label for="field_id">Label:</label> <input type="text"
name="field_name" id="field_id">
Anyone agree with this?
Gary Wilson
> Lakin Wecker wrote:
> > as_dl() gets a +1 from me. I've used definition lists for forms and
> > prefer it over tables. :)
>
> Maybe there needs to be an easy hook for people to specify their own way of
> laying a form out. It seems the as_ methods are gonna keep growing and growing.
+1
What if instead of adding various as_* methods that we have a
FormFormatter class that determines how the form displays. The
_html_output and as_* methods would become FormFormatters. Formatter
could be a parameter to the Form constructor, and could default to the
table formatter like how it is now. This would make Form display with
its FormFormatter similar to a form Field and its Widget.
This might even be something that would make sense as a setting,
default_formformatter. Usually one would not be mixing and matching
more than one formatter for a given site. If I wanted to change the
display of all the forms on my site, I could make the change in one
place instead of having to change all the as_p in my templates to
as_my_p.
Adrian Holovaty
> What if instead of adding various as_* methods that we have a
> FormFormatter class that determines how the form displays. The
> _html_output and as_* methods would become FormFormatters. Formatter
> could be a parameter to the Form constructor, and could default to the
> table formatter like how it is now. This would make Form display with
> its FormFormatter similar to a form Field and its Widget.
>
> This might even be something that would make sense as a setting,
> default_formformatter. Usually one would not be mixing and matching
> more than one formatter for a given site. If I wanted to change the
> display of all the forms on my site, I could make the change in one
> place instead of having to change all the as_p in my templates to
> as_my_p.
This is an interesting idea, but I think it's important to remember
the as_p(), as_table() and as_ul() shortcut methods are just
*shortcuts*. There's nothing stopping a developer from writing a
custom method on a Form, nor is there anything stopping a developer
from building the form "by hand" by piecing together the individual
fields.
as_p(), as_table() and as_ul() are just shortcuts for the common
(lazy) case when the developer doesn't want to spend time customizing
a form's display in the template. In my opinion, it would be
overengineering to create a separate framework (e.g., the proposed
FormFormatters) to provide for generic ways of being lazy. Put another
way, if we had a FormFormatter framework, that would encourage people
to use these "generic" form formats rather than giving tender loving
care to the design of each form, which is what I'd rather encourage.
Gábor Farkas
+1
gabor
Benjamin Slavin
> This is an interesting idea, but I think it's important to remember
> the as_p(), as_table() and as_ul() shortcut methods are just
> *shortcuts*. There's nothing stopping a developer from writing a
> custom method on a Form, nor is there anything stopping a developer
> from building the form "by hand" by piecing together the individual
> fields.
>
> as_p(), as_table() and as_ul() are just shortcuts for the common
> (lazy) case when the developer doesn't want to spend time customizing
> a form's display in the template. In my opinion, it would be
> overengineering to create a separate framework (e.g., the proposed
> FormFormatters) to provide for generic ways of being lazy. Put another
> way, if we had a FormFormatter framework, that would encourage people
> to use these "generic" form formats rather than giving tender loving
> care to the design of each form, which is what I'd rather encourage.
>
I agree with Adrian on this one. There are few common cases that
Django should handle... the flexibility is already there to allow
non-standard uses.