OK here's my new patch, adds a css='bla' option to your field
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, "Bri
Hey Wayne - I just submitted something similar - check it out
http://code.djangoproject.com/ticket/3515
On Feb 17, 6:57 am, "waylan" <[EMAIL PROTECTED]> wrote:
> FYI: I opened a ticket (#3512) and uploaded three separate patches.
> Personally, after working out all three, I think I prefer the thi
On Feb 16, 10:12 am, "Brian Morton" <[EMAIL PROTECTED]> wrote:
> I don't know if this has been suggested yet, but has anyone considered an
> enhancement to newforms to optionally allow a field to have a different
> class if it has an error? It would be helpful for things like making error
> field
On Feb 16, 1:07 pm, "waylan" <[EMAIL PROTECTED]> wrote:
> On Feb 16, 3:28 pm, "jfagnani" <[EMAIL PROTECTED]> 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 , , and elemen
On 2/16/07, jfagnani <[EMAIL PROTECTED]> wrote:
> 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...
{{
On 2/16/07, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Cool. I was looking at how I'd do this but I wouldn't have known
> about the add_to_class in __new__.
There are some notes on the wiki about how the model system works,
useful for anyone who wants to venture in there and patch stuff:
http://co
Cool. I was looking at how I'd do this but I wouldn't have known
about the add_to_class in __new__.
On Feb 16, 12:18 pm, "Gary Wilson" <[EMAIL PROTECTED]> wrote:
> Ticket and patch created:http://code.djangoproject.com/ticket/3511
--~--~-~--~~~---~--~~
You recei
On Feb 16, 3:28 pm, "jfagnani" <[EMAIL PROTECTED]> 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 , , and elements.
IMHO that addes no additional value. If you want the styling
FYI: I opened a ticket (#3512) and uploaded three separate patches.
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
(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 , , and elements.
For complex, non-linear forms, I place fields in the template via
{{ form.field }}, not with the as_ methods. I think the field
On Feb 14, 8:54 am, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
> I'm wondering if maybe get should raise an error with a name like
> "MultipleValueError" rather than "AssertionError" when multiple values
> are found...
Ticket and patch created:
http://code.djangoproject.com/ticket/3511
--~--~-
I think it makes sense to add them to _html_output as a list of
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
I started to write a patch for this and have a few questions. First, I
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 , , and elements for each
field as that seems to be the general consensus.
I saw this changeset go in and am wondering if it is possible to
specify a sequence order for the fields to display. Example:
class Person(Form):
first_name = CharField()
last_name = CharField()
class PersonWithMiddle(Person):
middle_name = CharField()
But where
On Feb 14, 8:54 am, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
> I'm wondering if maybe get should raise an error with a name like
> "MultipleValueError" rather than "AssertionError" when multiple values
> are found...
+1
--~--~-~--~~~---~--~~
You received this mess
As an example, ticket 3123 was re-opened and the stage remained ready
for checkin. I think it would be better if the stage was reset to
unreviewed when the ticket gets reopened. Thoughts?
Gary
--~--~-~--~~~---~--~~
You received this message because you are subs
Thanks! I've been looking for something like this for awhile.
On Feb 15, 3:09 pm, Thomas Steinacher <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I created a small library called "dynamicforms" (based on newforms)
> that allows you to edit multiple instances of an object
> simultaneously. It also prov
I intended to say something like this. And yes, and additional class,
not a different one. A required field one would be helpful as well.
On Feb 16, 4:57 am, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Marc Fargas Esteve wrote:
> > You could set the additional class to the container so you can u
Hi,
I've created a patch to allow the admin list_filter option to work
across multiple foreign keys using the '__' separator, for example:
class Town(models.Model):
name = models.CharField()
class House(models.Model):
town = models.ForeignKey(Town)
class Room(models.Model):
house =
If an "error" class is going to be added, we might as well take the
leap and add a "required" class, too.
On Feb 15, 7:12 pm, "Brian Morton" <[EMAIL PROTECTED]> wrote:
> I don't know if this has been suggested yet, but has anyone considered an
> enhancement to newforms to optionally allow a field
By container we should mean the most top element so it should be the
or that has the label and the input below it ;)
On 2/16/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> Marc Fargas Esteve wrote:
> > You could set the additional class to the container so you can use
> > simple CSS selector
Marc Fargas Esteve wrote:
> 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
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.
My 0.02,
Marc
On 2/16/07, Waylan Limberg <
23 matches
Mail list logo
