Local flavours content
Nebojša Đorđ ević
following:
How much of the information goes in there? Just the validation or we can
also put some the models there? I'm thinking to add cities with postal and
area codes and this data is more suitable for the database table than choice
list.
--
Nebojša Đorđević - nesh, ICQ#43799892, http://www.linkedin.com/in/neshdj
Studio Quattro - Niš - Serbia
http://studioquattro.biz/ | http://code.google.com/p/django-utils/
Registered Linux User 282159 [http://counter.li.org]
Malcolm Tredinnick
=?UTF-8?B?xJA=?=or=?UTF-8?B?xJE=?= evi=?UTF-8?B?xIcg?= wrote:
> I'm writing Serbian stuff for the localflavour but I'm not sure about
> following:
>
> How much of the information goes in there? Just the validation or we can
> also put some the models there? I'm thinking to add cities with postal and
> area codes and this data is more suitable for the database table than choice
> list.
Some background...
All the existing local flavors put these things in as static choice
lists. The logic being that they do not change over time.
I can see the logic of putting really large amounts of information in
the database, rather than storing it in memory. I would probably do the
same thing if I was trying to validate Australian postcodes against
cities.
To answer your query...
My impresions is that this isn't appropriate for the localflavor/
section, since it is meant to be for form data validation. We have
managed to keep that separate from the database backend so far. My
preference would be not to go overboard here -- validate that the cities
and postcodes are spelt correctly and have the right numeric format and
leave it at that. Otherwise there is just no end to the amount of data
people will want to include in Django.
So I'm -1 on using the database to store anything (or including so much
data that that becomes necessary). It would be interesting to hear other
opinions, though.
Regards,
Malcolm
Adrian Holovaty
> My impresions is that this isn't appropriate for the localflavor/
> section, since it is meant to be for form data validation. We have
> managed to keep that separate from the database backend so far. My
> preference would be not to go overboard here -- validate that the cities
> and postcodes are spelt correctly and have the right numeric format and
> leave it at that. Otherwise there is just no end to the amount of data
> people will want to include in Django.
>
> So I'm -1 on using the database to store anything (or including so much
> data that that becomes necessary). It would be interesting to hear other
> opinions, though.
The django.contrib.localflavor package is for any and every snippet of
Django code that could be useful for a specific country / location, so
it's not *just* limited to Form-related logic. For example,
django.contrib.localflavor.usa.us_states contains some helpful data
structures that people can use in their own applications, independent
of Form code.
But I agree with Malcolm that there should be some sort of limit to
the amount of data that we should include in there. If you want to
contribute some data that is so massive that it would best fit in a
database, it might not be the best candidate for localflavor.
Also, I'm not sure it makes sense to put models in localflavor,
because models are the types of things that people tend to want to
have control over, and we end up making subframeworks that let people
customize (see, for example, the User.get_profile() stuff).
Nebojša, does that help? If you're still unsure, it might help if you
gave more specifics on what sort of information/logic you wanted to
include.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Nebojša Đorđević
[snip]
> But I agree with Malcolm that there should be some sort of limit to
> the amount of data that we should include in there. If you want to
> contribute some data that is so massive that it would best fit in a
> database, it might not be the best candidate for localflavor.
> Also, I'm not sure it makes sense to put models in localflavor,
> because models are the types of things that people tend to want to
> have control over, and we end up making subframeworks that let people
> customize (see, for example, the User.get_profile() stuff).
This depends on the data in question. We are talking here about (IMHO)
very strict formated data (area codes, zip codes, organizational names,
...) which are usually defined by the one's country government so there
are no danger of sub framework explosion.
>
> Neboj˚a, does that help? If you're still unsure, it might help if you
> gave more specifics on what sort of information/logic you wanted to
> include.
I primary asked this because I want to include City - zip code - area
code data. This type of information is useful to have but it fits very
poorly with choice lists.
If I wanted to use choice lists I will probably come up with something
like this:
ZIP_CHOICES = ((1234, 'city name'), (1356, 'city name2),...)
AREA_CHOICES = ((12, 'city name'), (13, 'city name2'),...)
And this is what I want to avoid, repetition of the city names in the
booth lists.