Newforms styling suggestion
Brian Morton
Adrian Holovaty
Hey Brian,
I think we might have discussed this before, but the discussion
fizzled out. What would you want to style -- the form HTML tag itself?
The <label>? The table row (in case of as_table())?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Waylan Limberg
wrote:
I'd realy like to see this as well. I suppose either way would work, but
which is used needs to be consistent across all as_methods. Either isn't
always the containing block element or its always the label or it's always
the form element. The more I think about it, different people will want to
apply the style to one of any of those three possibilities. The only way
to be able to do so consistently is with the containing block. Oh, and
rather than "a different class" it should add an **additional** class. We
don't want to remove any classes that already exist.
--
Waylan Limberg
way...@gmail.com
Marc Fargas Esteve
simple CSS selectors to apply different styles to any element from the
container and inside it. Setting the class on the label or the input
field would not allow to modify the container.
My 0.02,
Marc
Ivan Sagalaev
> You could set the additional class to the container so you can use
> simple CSS selectors to apply different styles to any element from the
> container and inside it. Setting the class on the label or the input
> field would not allow to modify the container.
+1 (if by "container" we mean a <tr>, <p> or <li> in predefined methods)
Marc Fargas Esteve
<tr> <p> or <li> that has the label and the input below it ;)
Ceph
leap and add a "required" class, too.
rokcl...@gmail.com
not a different one. A required field one would be helpful as well.
waylan
was adding the classes 'error' and 'required'. I think those are
appropriate names. If anyone feels different speak now.
I am adding the class to the <tr>, <li>, and <p> elements for each
field as that seems to be the general consensus. I realize that some
may wish to either override or create their own as_methods in a
subclass etc. In so doing they may want to include their own html
classes assigned to every field. If the as_methods take this into
account, then the way I currently have it, every field which is not
required and without errors will get <tr class=""> which is not very
clean. As an alternative I could build the entire class definition and
only add it on error or required, but then we loose the ability to
include other classes on subclassing.
To work around the above problem, I could have _html_output() take
another argument allowing a list of html classes to be passed in.
Seeing we are already up to 5, that might be a little much. What do
you think? Or are people not writing their own as_methods, making this
a moot point.
rokcl...@gmail.com
classes (passed into the form object at creation) and have the default
as_ methods make use of them. Developers wishing to create their own
as_ methods can take advantage of them if they wish, or not. As for
the class names, I find them very reasonable (those names would be my
personal choice), but I personally think they should be passed as
arguments when the form is created, and that the class names should be
consistent for each error or required field throughout the form (i.e.
they should not be per field).
jfagnani
I think it's important to add the classes to the fields themselves, as
well as the <tr>, <li>, and <p> elements.
For complex, non-linear forms, I place fields in the template via
{{ form.field }}, not with the as_ methods. I think the field styling
is even more import in this case, because there's usually no room for
inline error messages. I'd like to print the error messages above the
form, and just highlight the fields.
It'd also be nice if fields had an 'error' property, so that you could
do some things in the template like {% if field.error %}
-Justin
waylan
Personally, after working out all three, I think I prefer the third
one. If we get some consensus on that, I'll see if I can find the time
to address tests and docs, of if anyone else gets to it first...
http://code.djangoproject.com/ticket/3512
On Feb 16, 2:38 pm, "waylan" <way...@gmail.com> wrote:
waylan
On Feb 16, 3:28 pm, "jfagnani" <just...@fagnani.com> wrote:
> (I think I lost an earlier reply, so hopefully this isn't a dupe)
>
> I think it's important to add the classes to the fields themselves, as
> well as the <tr>, <li>, and <p> elements.
IMHO that addes no additional value. If you want the styling to apply
to the field itself, just do for example:
.error input {border:solid 1px red;}
>
> For complex, non-linear forms, I place fields in the template via
> {{ form.field }}, not with the as_ methods. I think the field styling
> is even more import in this case, because there's usually no room for
> inline error messages. I'd like to print the error messages above the
> form, and just highlight the fields.
>
> It'd also be nice if fields had an 'error' property, so that you could
> do some things in the template like {% if field.error %}
I haven't used newforms this way yet (I've only used as_methods), so I
assumed that was already possable from the template. If not, that is
another issue. IMHO, this should be the only way (in the template) you
could add classes directly to the fields themselves. If you want
general usage, use the as_methods, if you want finer grained control,
use the templates to manualy build your forms.
James Bennett
> It'd also be nice if fields had an 'error' property, so that you could
> do some things in the template like {% if field.error %}
You can do this in the template as
{% if form.fieldname.errors %}
...special stuff here to highlight the field...
{{ form.fieldname }}
...close any tags opened before the input...
{% else %}
{{ form.fieldname }}
{% endif %}
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
jfagnani
On Feb 16, 1:07 pm, "waylan" <way...@gmail.com> wrote:
> On Feb 16, 3:28 pm, "jfagnani" <just...@fagnani.com> wrote:
>
> > (I think I lost an earlier reply, so hopefully this isn't a dupe)
>
> > I think it's important to add the classes to the fields themselves, as
> > well as the <tr>, <li>, and <p> elements.
>
> IMHO that addes no additional value. If you want the styling to apply
> to the field itself, just do for example:
>
> .error input {border:solid 1px red;}
How does that work if you don't have inputs enclosed in <tr>, <li>, or
<p> elements? The way I typically use form fields is by placing them
in the template with {{ form.field }}, not with the as_() methods, so
there won't be any .error elements to match against. It would be
annoying and repetitive to have to wrap every field with code to
highlight it in the template.
> I haven't used newforms this way yet (I've only used as_methods), so I
> assumed that was already possable from the template.
Jame's reply indicates that this is already possible, so I'll check it
out. I looked at the code and didn't notice anything in the field or
form classes that did this.
-Justin
sime
Yes that'd be nice, for sure. I guess we'd either set errors_css in
the class meta, or as an errors_css parameter when you create the form
object? Anybody has any preference let me know I'll get a diff
together :-)
In the meantime, some of you might be interested to explicitly set
field css classes. I couldn't find a way to do it yet, so here's a
diff below. Just set css='myclass' on your fields, eg
DateField(required=false, css='vDateField'). By the way, that example
there gives you nice little date pickers a la Django admin, when
combined with a couple of their javascripts.
--- fields.py Fri Feb 16 18:48:14 2007
+++ fields.py Fri Feb 16 18:47:30 2007
@@ -35,7 +35,7 @@
# Tracks each time a Field instance is created. Used to retain
order.
creation_counter = 0
- def __init__(self, required=True, widget=None, label=None,
initial=None, help_text=None):
+ def __init__(self, required=True, widget=None, label=None,
initial=None, help_text=None, css=None):
# required -- Boolean that specifies whether the field is
required.
# True by default.
# widget -- A Widget class, or instance of a Widget class,
that should be
@@ -60,6 +60,10 @@
extra_attrs = self.widget_attrs(widget)
if extra_attrs:
widget.attrs.update(extra_attrs)
+
+ # Allow a CSS class to be specified
+ if css:
+ widget.attrs.update({'class':css})
self.widget = widget
sime
http://code.djangoproject.com/ticket/3515
sime
definitions, also class='bla error' when there's an error, and
class='bla required' when the field is required (thanks waylan for the
idea on those last two points) --
http://code.djangoproject.com/ticket/3515
On Feb 16, 10:12 am, "Brian Morton" <rokclim...@gmail.com> wrote:
Tai Lee
> fizzled out. What would you want to style -- the form HTML tag itself?
> The <label>? The table row (in case of as_table())?
>
> Adrian
i'd like to see the data type classes from oldforms re-applied to the
form elements in new forms. e.g. class="vIntegerField",
class="vEmailField". these were great as they allowed differently
sized field elements depending on the data type. e.g. you might want a
textarea tag to be wider than an input text tag, you might want an
input text tag for an email address to be wider than an input text tag
for an integer or date.
if people don't want to make use of these, they can ignore them, but i
don't see the harm in having them in there as hooks, besides a few
bytes in html size. if that's a problem, they could be switched on or
off in settings.py or when the form.as_* and field.as_* methods are
called. not having these hooks appears to be a fairly significant
departure from the oldforms functionality, so i'd like to see it
removed only after some consideration.
as for the "error" and "required" classes being applied to the field
containers, i'd like to see these renamed to something less generic
and more form-specific. people may already have generic error or
required classes defined that they don't particularly want to apply to
the containers of forms with errors. "vError" / "vRequired" or "form-
error" / "form-required" or something similar would work for me.