Model fields vs form fields in localflavor
Andreas Pelme
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)?
I think it would be a lot more convinient and DRY, and the validation
logic would be applied in all modelforms automatically (and in the admin
interface) etc etc...
If not, where would it be recommended to put those (model) fields? Is
models.py a good choice? fields.py? How to make a clear distinction
between model fields and form fields?
Also, a lot of local flavors contains Select *widgets* for
provinces/states/etc. Why not create a form field too, with the widget
as default.
Am I missing something? Is there any reason *not* to do it, and just
stick to the form fields/widgets in localflavor? Has this been discussed
before?
Anyways: I will soon open a ticket with an initial patch for the Swedish
local flavor!
Cheers
--
Andreas Pelme <and...@pelme.se>
PGP/GPG key: 1024D/2F6D209F
Malcolm Tredinnick
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