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.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
