> On Thu, Jul 28, 2011 at 9:58 PM, bruno desthuilliers <
>
>> the __init__ method looks like the right place to handle this. First
>> make sure you exclude the related field from the ModelForm (cf the doc
>> for ModelForms on how to do this) and add your own field to the form
>> definition, and make sure you call on the supercall __init__ before
>> you populate the field.
>
> Seems like the only way, but I've always been a bit reluctant of overriding
> __init__ methods on Django core objects (models, forms, etc...),
You shouldn't.
> is there
> any concern I should have if I override __init__ apart of calling supers
> __init__ ?
When it comes to forms, there are a couple gotchas with fields
initialisation, specially when it comes to form.Fields vs
BoundFields. The main rule here is to always call on super __init__ -
passing it all the other args - *before* you do anything with fields -
but you can of course preprocess the args before calling on super
__init__ (specially "initials").
Also, a form (and even more a model form) has a somewhat lengthy
argument list with quite a few defaults. From experience, the best
thing is to use a simple (*args, **kw) signature and pass everything
to the superclass, or, if your form requires custom args, put them as
non-default arguments before the *args **kw part, so you don't have to
mess with the remaining ones.
And remember that Django is open-source so if you have any doubt, you
can always browse the source code. It's not exactly trivial
(metaclasses involved...) but it's still rather straightforward, no
frills Python code (nothing like Zope or else).
My 2 cents...
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment