Let's return to this subject, which was discussed a couple of weeks
ago. Here's my latest thinking on the subject.
* Automatic manipulators go away. Instead of messing with those, to
create a new model object you try instantiating it. Validation errors
are raised at that point. Example:
try:
c = Crime(crime_date='2006-1-2', crime_type='theft')
except ValidationError:
print "You have errors."
# Getting the errors
try:
c = Crime(crime_date='2006-1-2', crime_type='theft')
except ValidationError, e:
print e.messages # prints list of error messages (as strings)
* Specifically, validation happens on Model.__init__() and
Model.__setattr(), except when model objects are being loaded from the
database (e.g. Model.objects.get()). In the latter case, we can assume
the data is valid.
* This plan is nice conceptually because it doesn't leave any chance
of bad data in any model instance. Currently, Django is "dumb" about
data in model instances -- it allows any arbitrary data there, and
catching bad data is completely the responsibility of the developer.
This can lead to some IntegrityErrors at the database level (search
the django-users mailing list archives for examples) when the
developer forgets to validate.
* It's also convenient and conceptually nice to keep all logic --
including validation -- in the model object.
* Sometimes it'd be nice to turn off this validation -- for instance,
when mass-loading a bunch of data from a source you trust to be valid.
How should this work?
* As a side effect, multiple input types would need to be allowed for
certain field types. For example, a date field should accept either a
datetime object or a string in the correct format. Fields should
normalize input data to the correct internal type (in this case, a
datetime object) when the __setattr__() happens. For example, both of
these model attribute assignments would be valid:
c.crime_date = datetime.date(2006, 1, 2)
c.crime_date = '2006-1-2'
In the second example, c.crime_date would immediately be converted to
a datetime.date object. What are the pitfalls to this approach?
* As a side effect, generic create/update views will not be able to
use edit_inline stuff; that will only be an admin feature. I am 100%
fine with that, as I have never seen a need for using edit_inline out
of the admin -- it is an admin-specific phenomenon. We could indeed
expose the logic of determining edit_inline stuff so people can use it
for themselves, but it wouldn't be a core part of models, as is
currently the case with automatic manipulators.
That's all I had time to write up on a plane trip this evening.
Comments, thoughts, ideas?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~----------~----~----~----~------~----~------~--~---
