Model fields in localflavor

0 views
Skip to first unread message

Andreas Pelme

unread,
Oct 4, 2008, 8:13:29 AM10/4/08
to django-d...@googlegroups.com
[This messages is related to
http://groups.google.com/group/django-developers/browse_thread/thread/64e4d42590145347
]

On Jul 27, 11:39 pm, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> On Sun, 2008-07-27 at 16:39 +0200, Andreas Pelme wrote:
> > Hello
>
> > I have started writing a patch for adding Swedish (se) local flavor.
>
> > I looked at the code for other countries, and noticed that they only
> > contains form fields, not model fields.
>
> > Why is that? E.g. a postal code is very likely to be stored in a
> > database. Why not add default model fields (with appropriate
> > formfield(), validate() etc)?
>
> Well, right now, validation at the model field level isn't really
> supported. The old-style validators were only used by oldforms (and
> old-admin) and the new work that Honza Kral is doing isn't finished yet
> (although there'll probably be something done in time for the 1.0-beta.
>
> Even when that's done however, it won't require adding model fields for
> every type of localflavor. That would be overkill. Instead, it will be
> appropriate to add some validators for those particular types (and
> there'll be a fair bit of sharing with existing form validators).
>
> Realise that (a) almost everything is going to be stored in the database
> in a character field anyway, so different explicit Field subclasses
> doesn't add a lot and (b) you often aren't going to want a separate
> field column in the database for each locale. If somebody is entering an
> address, it will usually be stored in the same fields, regardless of
> whether they're entering an address in Sweden, Argentina or Australia.
>
> Regards,
> Malcolm

I finally got a ticket and patch created for the Swedish localflavor:

http://code.djangoproject.com/ticket/9289
http://code.djangoproject.com/attachment/ticket/9289/django_localflavor_se.diff

However, Swedish personal identity numbers are a little tricky, and can
be represented in a couple of different formats.

The appropriate thing would be to save the fields as their "long"
representation YYYYMMDDNNNN in the database. However, it is really
common to use them formatted as YYMMDD-NNNN, which creates some issues
with people older than 100 years. I wont go into more details about how
the numbers works, however, it would be really useful to do something
like this:

Having a model field with appropriate formfield(), that has the methods
long() and short() for outputting the identity number in the different
formats. You most likely want to store the data in the long format, and
mostly you are interested in the short format. It could also have
birth_day() that returns a datetime.date object.

My questions:
1) Would this be a good use case for introducing a model field in
localflavor(.se)?
2) If so, where should the tests live?
3) If not, with just the form field, the long(), short() and birth_day()
functions would still be very useful when dealing with these numbers.
Where should they live then? contrib.localflavor.se.utils?


Cheers
--
Andreas Pelme <and...@pelme.se>
PGP/GPG key: 1024D/2F6D209F

Reply all
Reply to author
Forward
0 new messages