Hi Lukash, I'm 0 to this.
I find it well thought out but in my use cases I fail to see the advantage
over the WAY 3 (or WAY 4 pointed out below) and it adds a layer of
abstraction where a straight tuple or a list does the job well enough.
The choice filtering could come in handy and in the end I don't see why this
can't co-exist with django's standard way.
WAY 4:
class UserManager(models.Manager):
GENDER_MALE = 0
GENDER_FEMALE = 1
GENDER_NOT_SPECIFIED = 2
GENDER_CHOICES = (
(GENDER_MALE, _('male')),
(GENDER_FEMALE, _('female')),
(GENDER_NOT_SPECIFIED, _('not specified')),
)
def males(self):
""" Returns all entries accessible through front end site"""
return self.all().filter(gender=self.GENDER_MALE)
def females(self):
""" Returns all entries accessible through front end site"""
return self.all().filter(gender=self.GENDER_FEMALE)
...
class User(models.Model):
gender = models.IntegerField(choices=UserManager.GENDER_CHOICES,
default=UserManager.GENDER_NOT_SPECIFIED)
objects = UserManager()
ef greet(self):
if self.gender == UserManager.GENDER_MALE:
return 'Hi, boy.'
elif self.gender == UserManager.GENDER_NOT_SPECIFIED:
return 'Hello, girl.'
else: return 'Hey there, user!'
-----Original Message-----
From: Łukasz Langa
Sent: Wednesday, April 04, 2012 9:15 AM
To: [email protected]
Subject: Re: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Dan Poirier w dniu 4 kwi 2012, o godz. 14:08:
One nice addition would be to specify explicitly what .id a particular
Choice should have. It would be useful in converting existing code that
might not have chosen to number its choices the same way this proposal
does by default. It looks like you could use Choices.Group(n-1) to make
the next choice defined use id=n, but that's not very elegant.
Right. The ability to explicitly set the .id on a single choice is useful.
The only reason it's not already there is that I didn't want to write my own
`makemessages`. Then again I might do just that. My proposal is based on
a working implementation because I didn't want to fall into bikeshedding on
what could have been theoretically implemented.
What we need now to push things forward is a list of +1, +1 if ..., +0,
+0 if ..., -1, "how dare you?!" from a bunch of people.
--
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer
IT Infrastructure Department
Grupa Allegro Sp. z o.o.
http://lukasz.langa.pl/
+48 791 080 144
--
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.
--
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.
