On Thu, Jan 22, 2009 at 7:39 AM, catsclaw <ch...@subtlety.com> wrote: > > Hi all -- > > I've started to poke around in customizing the generated form code > and providing my own widget instances, but the current Django form > code is written in such a way that it makes things nearly impossible.
First off - as a general guide, hyperbolae will get you nowhere. I can point to several places in the Django codebase where custom widgets are used to override the default widget, so "nearly impossible" isn't a fair comment. > 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. Yes - there are entry points where HTML attributes can be injected into this rendering process, and there are some entry points where the field can push attributes into the widget, but otherwise it is the widget that is rendered, not the field. The field isn't asked anything during the rendering process beyond "what is your widget?". > Adding a > widget therefore requires rewriting the field classes you want the > widget to be used with, rather than letting the widget interrogate the > field classes. That's not great design, and it means any changes to > form rendering becomes a major pain. Again - examples abound in the Django source tree that demonstrate that this simply isn't true. > 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. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
