On Thu, Jul 28, 2011 at 9:58 PM, bruno desthuilliers <bruno.desthuilliers@gmail.com> wrote:
I do create Test instances on demand here.
Seems like the only way, but I've always been a bit reluctant of overriding __init__ methods on Django core objects (models, forms, etc...), is there any concern I should have if I override __init__ apart of calling supers __init__ ?
This makes sense to me.
Thanks
Arkaitz
-- > I use a CharField and aErr... How do this work for not yet existing Test instances ?
> clean_test(): to convert the comma separated list of test names to a
> list of Test objects and this works perfectly.
I do create Test instances on demand here.
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...), is there any concern I should have if I override __init__ apart of calling supers __init__ ?
* "access" : in the __init__ method.
> Apart from that, is it good manners to access and create other Model
> objects from ModelForms?
* "create" : in the save method
> like in clean_ methods?
*don't*. The clean methods are about user inputs validation, and
should be idempotent (ie: should not alter the database state).
This makes sense to me.
Thanks
Arkaitz
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