On Jan 21, 5:37 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > > Here's just one example: when fields are written out to HTML, they > > get asked "what attributes does this kind of widget need?". > > Unless I'm misunderstanding your intent with this statement - No, they > aren't. A form contains fields, which describe the type of data that > is being collected and the validation procedures for said data. Each > field provides a widget, which describes a HTML element that allows > that data to be collected. When the form is rendered, it binds some > data to a field instance in a BoundField, and renders the BoundField > using the widget for the field.
Well, it seems to me that makes for an *extremely* tight coupling between the model and the view. And it's a little difficult for me to understand what value there is in such a tight coupling--if I've got a DateField, why can't I have it represented in an HTML page by a javascript calendar pop-up, or a text box, or three select boxes (month, day, and year). Plus, any time you collect a password you need to display it in a form using a password input, not the stock text input. And I might very well have two separate form fields which should be displayed as a single unit. There's a need to have the display decoupled from the form logic. Django just doesn't provide much help in doing that. > The field isn't asked anything > during the rendering process beyond "what is your widget?". Not true. There's a "widget_attrs" method on the base Field class which passes a widget and expects to be passed back a dictionary of attributes to be added to the widget. In other words, if I create a widget which renders a CharField and I'd like to validate the maximum length, I either *must* inherit from TextInput or PasswordInput, edit the CharField class, or write a different CharField class that's aware of my new widget. > > Is there any work being done to clean up the way Django creates > > forms? I saw there was something being done with DOCTYPE > > declarations, but it didn't look like that was making very extensive > > changes. > > In short, no. We completed a major refactor of the forms framework > just before v1.0 landed, and we're not really looking to make another > major change. > > However - our commitment is to backwards compatibility, not to no > change at all. If you have a specific problem that can't be solved, > feel free to make a specific suggestion on how to improve things. If I were writing it, I'd make the Form class responsible for defining the order of the fields, the labels, the validation logic and errors. The Fields would be part of that. I'd make a FormRenderer class which was responsible for drawing a form in different formats (as a list, as a table, etc ...) and Widgets would act as a bridge between a Field (or group of fields) and the FormRenderer. -- Chris --~--~---------~--~----~------------~-------~--~----~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
