2012/4/3 Łukasz Langa <[email protected]>:
> Explicit choice values::
>
> GENDER_MALE = 0
> GENDER_FEMALE = 1
> GENDER_NOT_SPECIFIED = 2
>
> GENDER_CHOICES = (
> (GENDER_MALE, _('male')),
> (GENDER_FEMALE, _('female')),
> (GENDER_NOT_SPECIFIED, _('not specified')),
> )
>
> class User(models.Model):
> gender = models.IntegerField(choices=GENDER_CHOICES,
> default=GENDER_NOT_SPECIFIED)
>
> def greet(self):
> if self.gender == GENDER_MALE:
> return 'Hi, boy.'
> elif self.gender == GENDER_NOT_SPECIFIED:
> return 'Hello, girl.'
> else: return 'Hey there, user!'
>
> This is a saner way but starts getting overly verbose and redundant. You can
> improve encapsulation by moving the choices into the ``User`` class but that
> on
> the other hand beats reusability.
I don't see the immediate need for Yet Another Sub-framework, as
described in this proposal. This is what I normally do, and it works
fine:
class User(models.Model):
MALE = 0
FEMALE = 1
GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')]
gender = models.IntegerField(choices=GENDERS)
def greet(self):
return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender]
If people aren't understanding that, we should improve our documentation.
Also, the fact that we *don't* have a sub-framework for this lets
people do whatever they want -- including using the dj.choices module.
So I am -1 on including this in Django proper.
Adrian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
