Hi Bruno, On 03/23/2011 08:56 AM, Bruno Renié wrote: > 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).
Aesthetic differences in the rendered HTML (like attribute order or linebreaks) is not a backwards-compatibility issue, IMO - though the default templates should still be functionally identical to the current output. I think widgets should maintain the same external API (i.e. the way they are used by Django's forms code should not change), or else follow the normal deprecation path for any well-justified changes there. As far as I can tell from a quick scan, the external API consists only of the signatures of the __init__() and render() methods, and the .attrs attribute (which is tweaked directly by BoundField). Any methods or attributes that are a) not documented, and b) not used by Django's form code outside of widgets.py, are IMO fair game for change (though obviously still only with good reason). The area where this is most likely to break user code is if people have subclassed some of the more complex widgets and are depending on internal implementation details in their subclass. My feeling here is that this is just like any other use of an internal API; all bets are off. If it turns out that this breaks a lot of code, the other option would be to introduce the new widgets in a new namespace, make them the default ones, and leave the old ones alone. I'd really like to not do this unless we absolutely have to. > 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. This sounds reasonable to me. > I'll post some updates here and on the ticket, in the meantime I'm > open to comments and suggestions. Great! Thanks for working on this. Carl -- 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.
