Model fields in localflavor

Skip to first unread message

Andreas Pelme

Oct 4, 2008, 8:13:29 AM10/4/08
[This messages is related to

On Jul 27, 11:39 pm, Malcolm Tredinnick <> 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:

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

My questions:
1) Would this be a good use case for introducing a model field in
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?

Andreas Pelme <>
PGP/GPG key: 1024D/2F6D209F

Reply all
Reply to author
0 new messages