> class Property(models.Model):
> def isValidUKPostcode(self, field_data):
> p = re.compile(r'^(GIR
> 0AA|[A-PR-UWYZ]([0-9]{1,2}|([A-HIK-Y][0-9](|
> [0-9]|[ABEHMNPRVWXY]))|[0-9][A-HJKSTUW]) [0-9][ABD-HJLNP-UW-Z]{2})$')
> if not p.match(field_data['postcode']):
> raise validators.ValidationError("You have to have a
> space in the
> Postcode and all Capital letters.")
<rant>
I'm gonna raise a personal pet-peeve here...if the computer can
reformat/clean the incoming value, it should do so. Unless the
space has specific syntactic value, you should normalize
everything to an uppercase format with no spaces, and /then/
validate it. Or allow your validation to accept a sloppy value
and then normalize it before you save.
Either way, there's very little more user-abusive than requiring
them to enter such things (phone numbers, ID numbers, credit-card
numbers, etc) in an exact format. PARTICULARLY when spaces are
involved. I had one site require that a US phone# be formatted
as "(999) 999-9999". I had to type the bloody parens, the dash,
AND THE [expletive] SPACE before the form validated.
On the other end of the spectrum, our VoIP system's web portal
allows phone numbers to be entered in such a flexible number of
ways that as long as I use numbers, it takes it. With any
mixture of dashes, periods, parens, spaces, or none of the above,
it normalizes it into an internal format, and then displays it in
a uniform fashion.
</rant>
My understanding of the "right/Django" way to do this using
newforms is to use the clean_* methods to normalize this data
before it gets shoved off to the DB, and that these clean_*
methods would look something like
clean_postcode_re = re.compile('[^0-9a-z]', re.I)
def clean_postcode(self):
return clean_postcode_re.sub('',self.postcode).upper()
However, this seems to do it on a (newform)Field-by-field basis.
I couldn't find much in the way of affixing such functionality
to a Model field. The best I've been able to determine, one uses
a custom model field as decribed here:
http://www.djangoproject.com/documentation/model-api/#custom-field-types
with it's caveat about "read the source and if it breaks, you get
to keep both pieces". One would then override the
get_db_prep_save() method to take the raw value and return the
reformated/cleaned version (such as stripping out non-digit
characters from a phone-number field).
Is there an analog function for formatting things coming *out* of
the DB? Using the phonenumber example, one might want to use the
get_db_prep_save() to strip out anything non-numeric, and then
store that form in the DB, but then when getting the field,
display it as a formatted number. E.g:
"800.555.1212" from the user
-> "8005551212" in the DB
-> "(800)555-1212" coming back out from the DB
-tim
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
