How about a decorator over constructors?
USZipCode = FieldWithValidation(CharField, [isUSZip])
How about this syntax? something like oldform style?
USZipCode = CharField( validators=[isUSZip] )
--~--~-~--~~~---~--~~
You received this message because you are
Webda has a lot of localization information already compiled -
http://webda.python-hosting.com/
Including, countries, areas (states, etc), languages, phone numbers.
It already had Django modules so it could be a good contrib to add.
I do agree that most of these are char fields and the
FieldWit
On 1/18/07, telenieko <[EMAIL PROTECTED]> wrote:
...
On fields like USZipCode or USState and those which are **really** region
speciffic could be put on contrib (why would somebody outside US want those
fields? ie) we could end up with SpainRegion, CaribeanIsland... you get the
idea.
It seems
Hi,
Some of those fields could, maybe, be solved on a way like the one I just
submitted to #1636. Basically IPAddressField could have an option about
whether it should or shouldn't accept cidr notation IP's as the field is
**almost** the same it could be an elegant way to have both in one ;)
On f
[EMAIL PROTECTED] wrote:
Many of these have working patches and are ready to go, but I'm
wondering if we want to proliferate the number of field types? I think
that adding too many of these is just adding clutter ( e.g.
EthernetAdress vs. IPAddress vs. CIDR etc ) and especially since a
CharField
[EMAIL PROTECTED] wrote:
Evening all,
I've been digging through Trac and found that there's a number of
tickets related to adding new database Field types:
Is there any documentation on adding your own field type? This might
alleviate the need to centralize some of the smaller field types.
Evening all,
I've been digging through Trac and found that there's a number of
tickets related to adding new database Field types:
http://code.djangoproject.com/ticket/1466 USZipCodeField
http://code.djangoproject.com/ticket/1636 CIDR Datatype
http://code.djangoproject.com/ticket/1642 DirPathFi
