Re: Newforms styling suggestion
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 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 , , or
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
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Newforms styling suggestion
(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 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
On Feb 16, 11:38 am, "waylan" <[EMAIL PROTECTED]> wrote:
> 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 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 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.
>
> On Feb 16, 8:47 am, "Ceph" <[EMAIL PROTECTED]> wrote:
>
> > 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 to have a different
> > > class if it has an error? It would be helpful for things like making
> > > error
> > > fields highlighted red, etc. Just a thought.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: newforms, "reverse inline" editing, fieldsets
On Feb 2, 1:17 pm, "Frankie Robertson" <[EMAIL PROTECTED]> wrote: > Sorry, I had some trouble understanding your situation. So I'm not > sure, but isn't this what prefixes are for? I suppose they're a bit > tedious to use (what with having to inject the id of the child row > into the clean_data of the parent row and shoving the whole thing into > a transaction) but not that bad. I've got some somewhat non-trivial > code involving four interrelated objects being added that isn't really > open but I could possibly share if you're having problems. I haven't come across prefixes yet, so I don't know. I guess I'll check it out. My situation really is just that I have relationships that point in the opposite direction than Django expects: they're not going from child to parent, but parent to child. The is preventing me from getting a form object that automatically has the fields I want and saving correctly. > Or is it to do with the scaffolding and things not appearing in the > right order? No, I'm not using the form.as_table(), etc. methods. I'm placing the fields into my template directly. > The point in scaffolding is that it was only made to be knocked down. True, but the more cases that Django can automatically deal with, the better. I feel like it's almost able to handle what I'm doing, with the exception of these few relationships, and it's seems like a bit of a pain to graft on a few things to the scaffolding. Thanks for the reply. I'll look into prefixes, but they're not in the docs yet. I'll ask on the user list. --Justin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
newforms, "reverse inline" editing, fieldsets
I've been using Django for a few months now and have recently started looking into newforms. I was hoping that it would solve some issues I was having with the old Manipulator/FormWrapper way, but one thing is still a little painful to do when it seems like it could be handled automatically. I have an Order table, which for the most part is setup how you would expect: fields for order_number, date, customer, etc. Then there's the OrderLineItem model with a ForeignKey field to Order. Again pretty standard. Where the situation deviates is with addresses. I have an Address model that I use for addresses all over my application (not just in orders). Orders have three addresses: billing, shipping, and third_party_billing. So I've created 3 foreign key fields for them (with unique related_names, of course). This issue is that I want to edit the addresses with the order, so the edit_inline argument doesn't work for me. I also don't want to add a field to Address to relate it to Order, since I use Address in other places. What I lose is the ability to use form_for_model() in a nice way. I think a great addition to models and newforms would be a way to model what I'm doing and still get the scaffolding features. That doesn't seem like it'd be too difficult. Barring that, another solution is to add fields to the form returned by form_for_model(), then remove them from clean_data so there's no exception on form.save(). This is probably what I'll do, but it seems unnecessarily tedious. Something that would help there would be fieldsets. Then form.fields['shipping_address'] could be a fieldset. Maybe even better would be something like form.fields['shipping_address'] = form_for_model(Address). This subform could validate and save to the database and return the primary key for saving the parent form. Well, I'm interested in see what the developers have to say. Do my thoughts make sense here? Would these things be difficult to add? Thanks, Justin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
