On Sep 16, 10:08 pm, Gerard Petersen <[EMAIL PROTECTED]> wrote: > Daniel, > > Great one! Your suggested setup works, in the front-end that is. I have quite > some classes subclassed from ModelAdmin (including ProductAdmin), however the > "form = ProductForm" line breaks my app. I've tried several import statements > to get the droplist to work in the admin part. This one worked: "from myforms > import ProductForm" however for some strange reason it now breaks on Meta > class for the CustomerForm: > > http://paste.pocoo.org/show/85458/ > > ... completely dazzled .. Any tips?
Urgh, not enough information. My only clue would be that 'from foo import *' is a recipe for disaster - you're importing everything in the module into your namespace, and that means things could be overwritten somewhere. Use 'from models import MyModel, MyOtherModel' and 'from django import forms' (then refer to forms.ModelForm etc). > One concept Q: Why is it that the DB query statements to 'build' the > BTW_CHOICES don't get executed in models.py and do get executed in the > myforms.py It's because the model is defined declaratively: that is, each of the model fields is declared as a class-level attribute, and Django uses some clever metaclass stuff to actually turn them into instance properties (way over my head, I'm afraid). So you can't put dynamic code there - it would only ever get executed once, when the model is first defined. What we've done with the form is override the __init__ method which is called whenever a new form is instantiated. So our query is executed every time, making the choices dynamic. -- DR. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
