Malcolm Tredinnick wrote:
>You don't explain whether you are using oldforms or newforms here.
>
>
Right - at the moment using oldforms with generic views, I'm not yet
really familiar with newforms. I'm quite new to Django :)
>For newforms, override the Field class(es) that you wish to customise
>and write new clean() methods. Your methods could just call the
>super-classes clean, catch ValidationError and replace it, or do
>something more if you wanted.
>
>
That makes sense. However, as I stated above, I'm still using oldforms
(I decided to be on 'safe & stable' side).
>For oldforms, you would need to replace the validator_list entries in
>the Fields you are interested in, I guess. Have a look at the source
>code (django/db/models/fields/__init__.py) to see how validator_list is
>used in each class you are interested in.
>
>
Tha's what I did - I've created a simple validator wrapper (consider it
'proof of concept' quality):
class ValidatorWrapper:
def __init__(self, validator, msg):
self.validator = validator
self.msg = msg
def __call__(self, field_data, new_data):
try:
self.validator(field_data, new_data)
except ValidationError, e:
raise ValidationError(self.msg)
Now I instantiate my model fields like this:
firstname = models.CharField("Firstname", maxlength = 100,
validator_list = [ ValidatorWrapper(isNotEmpty, 'My custom message') ] )
I know it is ugly, but it works...
Why not make every validator a callable object (as opposed to a plain
function), that would take the error message optional param? Like this:
firstname = models.CharField("Firstname", maxlength = 100,
validator_list = [ isNotEmpty( message = 'My custom message') ] )
Even more, validator could also check if message is string or callable,
in the second case call it to obatin real error message, passing it the
field/object. Of course, this shall be done in a base class for all
validators.
>In either case, if you are creating a form directlly from the model,
>instead of manually, you pretty much have to live with the error
>messages we give you. The automatic creation is always designed for teh
>simple, straightforward case. Any customisation requires a bit of code
>on your part.
>
>
Obviously, the question is however, how elastic the framework is, and
thus how much extra coding is needed to do the customizations.
BTW, I'm new to Django, but not new to web apps in general. I've done a
few in java, Perl and PHP. What I consider a good practice is to move
error messages down to the view/template. Error condition belongs to
model, but error message I feel belongs more to view layer.
BR,
Przemyslaw
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
