Newforms: colon after label
vfoley
I rewrote the forms portion of an application by using newforms. It's
pretty nice, however there is something extremely annoying: newforms
automatically adds a colon after labels (hopefully, my formatting is
correct):
Out[58]: class ExampleForm(forms.Form):
name = forms.CharField(label='Your name')
yob = forms.CharField(label='Year of birth')
In [59]: example = ExampleForm()
In [60]: print example.as_p()
<p><label for="id_name">Your name:</label> <input type="text"
name="name" id="id_name" /></p>
<p><label for="id_yob">Year of birth:</label> <input type="text"
name="yob" id="id_yob" /></p>
See? I specified the label to be "You name" and "Year of birth"
without the colon, but newforms adds it automatically. I think this
is set on line 124 of django.newforms.forms.py:
label = bf.label and bf.label_tag(escape(bf.label + ':')) or ''
I don't think the library should add text like that, what do you
think?
Vincent.
P.S: This code is from 0.96, I haven't checked the Subversion tree.
SmileyChris
> Hello,
>
> I rewrote the forms portion of an application by using newforms. It's
> pretty nice, however there is something extremely annoying: newforms
> automatically adds a colon after labels (hopefully, my formatting is
> correct):
This is the way that it has been decided to handle the labels in the
"lazy" methods. You aren't forced to use these methods.
> P.S: This code is from 0.96, I haven't checked the Subversion tree.
You won't see any difference, except that I have a ticket which will
only add the colon if there is no other punctuation to be added soon.
Hrm... I guess a ' ' could be added to my check for punctuation, in
which case it would leave the colon off if you ended in a space. Meh,
maybe that's a bit to "magic".
David Danier
> I don't think the library should add text like that, what do you
> think?
I really think it should. The methods defined in the form are some
default, that can be used if appropriate. If not newforms is usable in
any way you want. You can use all the flexibility Python and newforms
provides here:
I use this (colon-free) code for form-display:
(put into a separate file that is included in the templates)
-----------8<--------------------------------------------------------
{% for field in form %}
<div>
<label><span>{{ field.label|escape }}</span> {{ field }}</label>
{% if field.errors %}<div class="error">{{ field.errors|join:",
"|escape }}</div>{% endif %}
</div>
{% endfor %}
-------------------------------------------------------->8-----------
(<label> includes field to get it working in the IE, <div> for
linebreaks, that even work in text-browsers and because normal lines
cannot be styled using CSS)
You could even write your own Form-class (extending newforms.Form), that
outputs other things (e.g. by just adding an as_my_style()-method and
using this as default). If you really want to change many thing you can
create your own forms-module (importing newforms.* and overwriting
things you need to change). I use this way to have an drop-in
replacement for the forms without forking the main-code. I changed the
date-fields to accept german notation for example. The big advantage
here is that forms.DateField can be used, so nothing needs to be changed
(except for the input-statement).
Perhaps the colon can be moved into the display-methods (as_p, as_ul,
...) or an parameter/attribute could be added to the form, but as most
people use forms with colons and newforms provides anything you need to
display something different I think this should stay default.
Greetings, David Danier
Jonas Maurus
I think that this is a very bad solution. If the framework does
something small magically, like adding a colon, there has to be a way
to remove it without a *big* change like, for example, writing a
custom template, referencing every form-field by itself, just to
remove a colon.
Also, there simply are languages where this punctuation doesn't make
sense. Adding it automatically then telling international users that
they have to write a lot more code, because english developers wanted
to save one character is bad, I think. Imho, adding even more magic to
make it go away, makes even less sense.
Not to mention that there are a lot of layout choices that would make
this colon superfluous.
What's wrong with
name = forms.CharField(label='Your name:')?
I'd definitely go for removing this altogether before it's to late.
Best regards from Germany,
Jonas
bromer
> Also, there simply are languages where this punctuation doesn't make
> sense. Adding it automatically then telling international users that
> they have to write a lot more code, because english developers wanted
> to save one character is bad, I think. Imho, adding even more magic to
> make it go away, makes even less sense.
>
> Not to mention that there are a lot of layout choices that would make
> this colon superfluous.
>
> What's wrong with
> name = forms.CharField(label='Your name:')?
>
> I'd definitely go for removing this altogether before it's to late.
I think there are lots of situations where you need to normalize the
labels with some string. Why not just make it an optional parameter to
the Form class with a default value.. maybe ":"?
Rune
Jonas Maurus
so that would make
name = forms.CharField(label='What role do you want to play?')
into
name = forms.CharField(label='What role do you want to play',
punctuation='?')
for *sometimes* saving you from typing one character? I still think it
makes no sense to append anything at all. Not to mention the pending
unicodization... the Japanese, Chinese, Korean and Cyrillic alphabets
don't use western punctuation...
Unless there's a better argument than sometimes saving one character
or being backwards-compatible to 0.96, I'm still against this.
However, I don't carry much weight around here ;-)
cheers,
Jonas
Todd O'Bryan
> > I think there are lots of situations where you need to normalize the
> > labels with some string. Why not just make it an optional parameter to
> > the Form class with a default value.. maybe ":"?
> >
> > Rune
>
> so that would make
>
> name = forms.CharField(label='What role do you want to play?')
>
> into
>
> name = forms.CharField(label='What role do you want to play',
> punctuation='?')
>
> for *sometimes* saving you from typing one character? I still think it
> makes no sense to append anything at all. Not to mention the pending
> unicodization... the Japanese, Chinese, Korean and Cyrillic alphabets
> don't use western punctuation...
>
> Unless there's a better argument than sometimes saving one character
> or being backwards-compatible to 0.96, I'm still against this.
> However, I don't carry much weight around here ;-)
I think he was suggesting in the form, not each field:
form = forms.Form(punct='')
would let you create a form with no colons. You could also do something
like
form = forms.Form(punct='-->')
or whatever. This would also allow you to override the punctuation based
on locale. Seems like a not bad solution. People who hate the colons
could create their own subclass of Form and use it instead of the
default form and then they wouldn't have to set the punct value each
time.
Todd
Jonas Maurus
You're of course right.
I see that this would allow Django to be backwards-compatible by
introducing this new parameter, so I could go for that because I think
backwards-compatibility is very important. I still disagree with the
concept anyway because I think that:
* it's a newbie-trap ("where does this colon come from it's neither
in the template nor in my string???"and
* it doesn't really save any significant amount of time or space (12
characters saved on a form with 12 fields) and
* it splits your label string between two classes so it's a concern
for l10n and
* it's not very friendly to languages that don't use english/western
punctuation
So I guess it comes down between backwards-compatibility and "doing
the right thing as currently defined by Jonas Maurus". I think that
it's clear that requiring to write a full template for all form-fields
just to remove the colon would be really bad, at least. Btw, how does
the Django-community usually decide such a thing? by a vote like in
Apache projects? or do we wait for one of the core developers to show
up? :-)
cheers
Jonas
Istvan Albert
I think the OP is correct, if you want the label to end with a
colon ... then add the colon to the label. It doesn't get any simpler
than that. Any other solution just gets in the way.
i.
Ted
forms. Something as simple as a ":" is not a given. Maybe I want a
" :" instead? This could be a form parameter or even a locale setting.
My 2 cents,
Ted
James Bennett
> Were I work we have had to do this very thing to support I18N in our
> forms. Something as simple as a ":" is not a given. Maybe I want a
> " :" instead? This could be a form parameter or even a locale setting.
FWIW I think the ideal would be for the default string representation
of the form to not add any punctuation at all -- adding options to
configure this just feel too ugly, so the proper solution should be
for the form to not do it, and trust to application developers to
present the form in whatever way they want (if that means no
colon/other punctuation, then the default will still be fine; if not,
the templating isn't all that complicated and provides absolute
control of the output).
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Rune Bromer
>> I think he was suggesting in the form, not each field:
I did :)
> I see that this would allow Django to be backwards-compatible by
> introducing this new parameter, so I could go for that because I think
> backwards-compatibility is very important. I still disagree with the
> concept anyway because I think that:
>
> * it's a newbie-trap ("where does this colon come from it's neither
> in the template nor in my string???"and
> * it doesn't really save any significant amount of time or space (12
> characters saved on a form with 12 fields) and
> * it splits your label string between two classes so it's a concern
> for l10n and
> * it's not very friendly to languages that don't use english/western
> punctuation
>
> So I guess it comes down between backwards-compatibility and "doing
> the right thing as currently defined by Jonas Maurus". I think that
> it's clear that requiring to write a full template for all form-fields
> just to remove the colon would be really bad, at least. Btw, how does
> the Django-community usually decide such a thing? by a vote like in
> Apache projects? or do we wait for one of the core developers to show
> up? :-)
I would agree that the punctuation should not be there at all, as it's
easy to add it to the label yourself.
If - on the other hand - we want the parameter on the form I would be
happy to write a patch.. should be quickly done..
Rune
olive
On 29 mar, 16:34, "James Bennett" <ubernost...@gmail.com> wrote: