Hi Carl, On Tue, Mar 15, 2011 at 6:59 AM, Carl Meyer <c...@oddbird.net> wrote: > > As we've already discussed here at PyCon, I'm +1 on this change. It > makes forms far more flexible and usable by template authors, and I > think that will benefit almost all Django users. It's more consistent > with Django's philosophy that presentation issues should be accessible > to template designers who are not necessarily Python programmers. > > There is the speed tradeoff, and I sure hate to do anything that we know > is slower. But I feel like this is a case of "do it right, then make it > fast" - and I just think this is clearly the right way to do it. > Probably the right way to make it fast is to make the template engine > fast (Alex Gaynor had some interesting proposals for that for last > year's GSoC, though it got dropped in favor of the no-SQL stuff). In > absolute terms, I think the speed difference is already small enough > that only a small fraction of users will be impacted by it, and they > would always have the option to replace the default widgets in their > forms with their own faster versions. > > The auto-escaping is another significant advantage - it's quite easy to > forget to escape something that should be escaped in a custom widget (we > had such a bug in Django itself until the latest security release), and > I think it can only be good for security to discourage people ever > building HTML strings in Python code. > > I already use floppyforms on all projects, and don't have any issues > with the widget API it provides. > >> This could be part of a broader change related to form rendering (e.g. >> fieldsets, looping over fields, etc) but I haven't thought about this >> enough to have a concrete proposal. For more information, see that >> discussion that happened at Djangocon: >> >> https://github.com/SmileyChris/django-forms/wiki/Django-form-API-ideas > > Although these proposals are related, and will involve some similar > changes (i.e. the need to be able to load default form templates), I > think the broader questions about form-rendering tags still need more > work, and converting the built-in widgets to use templates doesn't need > to be delayed while we hammer all of that out.
With 1.3 out (yay!), I just created a ticket to track the progress on this: http://code.djangoproject.com/ticket/15667 I'm working on a patch, I'll attach it to the ticket as soon as I'm happy with the widgets code and the regression tests pass again. I'm not sure, however, how django's backwards-compatibility applies in this case. The widgets API has never been publicly documented but the official documentation encourages people to look at the code and create their own widgets based on it. Is it fine to touch some internal methods like build_attrs()? There will be some minor differences in the rendered code, with things like the order of attributes (name='foo' id='bar' versus id='bar' name='foo') and linebreaks (I have an EOL at the end of every template so each widget gets a "\n" at its end). Currently the base `Widget` class has a render() method that raises NotImplemented. I think the rendering logic should happen here, the base Widget class should accept a template_name attribute and a render() method that renders the template. This way there is (almost) no need to touch any widget's render() method since template_name and get_context_data provide the needed extension points. I'll post some updates here and on the ticket, in the meantime I'm open to comments and suggestions. Regards, Bruno -- 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.
