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? 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 Thanx again! Regards, Gerard. Daniel Roseman wrote: > On Sep 15, 9:34 pm, Gerard Petersen <[EMAIL PROTECTED]> wrote: >> Daniel, >> >> I'm building an invoice system. The data relations are as follows: >> >> Customer -1toN-> Orders -1toN-> Products >> >> The products can have different tax levels which, during creation of an >> order, get chosen by the user from a drop downlist. As shown in my first >> email, a tax level value (e.g. 0%, 6% or 19%) gets copied to a >> product.tax_level attribute from the metadata model. Since the value of >> those taxes can change overtime (by law), I copy them. If I don't copy them >> (and use relationships), adjusting the value to a new tax level would >> 'cripple' the old orders. Note that performance or normalisation is >> currently not a priority, code and app readability is. Then since it's a >> copy of the tax value level to the product it does not have to be a >> relationship, and thus a lookup will suffice. >> >> Hence my earlier question, how can I fill a dropdown list (BTW_CHOICES) with >> values from a (different) model. >> >> # MetaData model:http://paste.pocoo.org/show/85368/ >> - The display represents the value that the user sees in the dropdown list >> (see below). It can be compared with the __unicode_- function for objects. >> - The value is the actual value that is copied and on form submission stored >> in the product object >> >> # Product Model:http://paste.pocoo.org/show/85370/ >> >> The way BTW_CHOICES should be filled is '(attribute, display)' taken from >> the metadata model: >> >> BTW_CHOICES = ( >> ('0.0', '0%'), >> ('6.0', '6%'), >> ('19.0', '19%'), >> ) >> >> I hope this clearifies things. >> >> Thanx a lot for your interest and help! >> >> Regards, >> >> Gerard. > > > Hmm, an interesting problem, and I wouldn't necessarily argue with > your decision to go a bit denormalised. > > I would probably approach this in a slightly different way. Rather > than worrying about the choices in the model, I would concentrate on > the form. Just about the only thing that defining choices in the model > field would give you would be a get_tax_level_choices() method, which > returns the display value rather than the database value. However in > your case this is of little use as the values are the same, with the > addition of the % symbol - so it's not worth it. > > So I'd do something like this: > > > DUMMY_CHOICES = ((0, 0),) > > class ProductForm(forms.ModelForm): > tax_level = forms.ChoiceField(choices = DUMMY_CHOICES) > > class Meta: > model = Product > > def __init__(self, *args, **kwargs): > super(ProductForm, self).__init__(*args, **kwargs) > self.fields['tax_level'].choices = [(m.value, m.display for m > in MetaData.objects.all()] > > class ProductAdmin(admin.ModelAdmin) > form = ProductForm > > admin.site.register(Product, ProductAdmin) > > > This code registers the form in the admin, although of course you can > also use the form on the front end if you like. (I've included the > line referring to ChoiceField/dummy choices, as if you take the > choices attribute out of the model field declaration you won't get a > ChoiceField by default in the ModelForm. You could use the existing > BTW_CHOICES tuple there if you like, but whatever values are in it > will be overridden by the queryset in __init__.) > > -- > DR. > > -- urls = { 'fun': 'www.zonderbroodje.nl', 'tech': 'www.gp-net.nl' } --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
