[This messages is related to http://groups.google.com/group/django-developers/browse_thread/thread/64e4d42590145347 ]
On Jul 27, 11:39 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> PGP/GPG key: 1024D/2F6D209F --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
