@ Nader : i think you got it, just give it a try! if it doesnt work
django will tell you anyway ;) You define a function that gets called
on validation of the field is the very abstract view of it as i
understand it.
On Oct 10, 6:34 pm, Tim Chase <[EMAIL PROTECTED]> wrote:
> > 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>
I agree with that! And i will probably make it better. Still
learning ;)
>
> 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()
>
do you need to do clean in the admin as well?
o
> 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
-~----------~----~----~----~------~----~------~--~---
