Hi Nate, On Thu, 5 Apr 2012, Nate Bragg wrote:
They don't "have" to be replaced in a subclass in the way you showed. Perhaps it isn't perfectly DRY, but whats so bad about naming the field explicitly?
The fact that we're building reusable components and we want people to be able to subclass our forms and:
* change field and widget properties * do so depending on run-time configuration (e.g. the database or settings) * even if the inherited field type changes * or the inherited options change * and get an error if they reference a field that doesn't exist any more Besides which, it's unnecessary, repetitive and unclear what one is doing.
Anyhow, when it comes specifically to widgets, the Meta class already has a 'widgets' attribute already that lets you specify that.
Thanks for reminding me about that. It's a bit difficult to inherit through multiple levels of subclasses, and doesn't generate errors if one refers to a field or property that doesn't exist, but it meets most of my requirements.
I would sooner have "smart" Meta class attributes to perform this behavior declaratively than to have to do it at the __init__ level: class Meta: title__required = False programs__help_text = 'Hold down Ctrl to select multiple options' authors__required = False confidential__widget = AdminYesNoWidget uploader__required = False file__widget = AdminFileWidgetWithSize
Yes, that would work too, although it also doesn't generate errors if one refers to a field or property that doesn't exist,
... and I don't like *that* particularly either.
Do you really dislike the idea of making form field properties settable after creation using @property and behave sensibly? It seems neat, simple, small, powerful and pythonic to me.
Cheers, Chris. -- Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838 Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK Aptivate is a not-for-profit company registered in England and Wales with company number 04980791. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. 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.
