Hi Simon,
On Fri, 6 Apr 2012, Simon Meers wrote:
On 6 April 2012 07:26, Beres Botond <[email protected]> wrote:
Isn't it this what you are trying to do?
class DocumentForm(ModelForm):
def __init__(self, *args, **kwargs):
super(MyForm, self).__init__(*args, **kwargs)
self.fields['title'].required = False
Which works perfectly fine. You can tweak pretty much any property at
runtime like that, without replacing the field entirely.
This discussion is sounding more like something that belongs in
django-users. I agree that there are some improvements that can be
made to make field-tweaking easier and more elegant, as proposed in
[1] which Keryn pointed out in [2]. It would probably be better to
continue this conversation in those tickets.
Simon
[1] https://code.djangoproject.com/ticket/17924
[2] https://code.djangoproject.com/ticket/18064
Now unfortunately both tickets have been closed by a core developer, so I
apparently have no choice but to try to persuade people here if I want to
reverse that.
There is an important use case on my ticket [2] which is not covered by
[1], which is controlling properties depending on run-time information.
For example:
* we have drop-down list controls whose choices depend on database
queries, and which must not be cached in the form class, because we can't
restart the server just in order to show changes in those lists.
* similarly, whether a field is required or not might depend on the value
of another field, or in another related model.
We CAN use __init__ to either replace the fields, or poke values into
fields and their widgets, but it's not clean: it's excessive code and the
excess code is entirely Django internals that are subject to change. For
example, we currently have to know that we need to change the widget's
values as well:
self['title'].required = False
self['title'].widget.is_required = False
whereas if that was handled by a property setter, we'd only have to do
this:
self['title'].required = False
and the amount of code in Field is the same, but much of the code from
__init__ is separated out into individual setters. I hope that you will
agree that this is cleaner, more reusable design, which allows fields to
respond intelligently to changes to their properties after creation.
(If you don't agree, is it because you're in the "everything should be
declarative" camp? I have issues with that position: mainly that sometimes
some things cannot be known until run time; so we should support doing
everything at run time, even if we have some magic sugar for doing it
declaratively as well, when that's possible).
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.
