""" 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? """
Providing this type of "Magic" is a bad idea because it's not explicit
in form, and doesn't promote consistency.
"""* 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. """
IMHO the admin should reflect the capabilities of the framework, but
shouldn't be part of it. In theory I should be able to create my own
"Admin" application with all of the current features of the existing
admin just using the framework. If it was an important feature in the
admin application, that functionality will probably be useful to
someone else. Essentially, the admin should be the first killer Django
application.
"""* 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."""
Promoting best practice is good, but having it built in would be
GEAT!!!
"""I would propose to instead do validation in those situations where
the
data is moved to the external storage - on .save() (or in the
unit-of-works .save() if we have them). That way you can happily create
invalid objects, but you will be forced to make them valid to save
them. An additional .validate() method could be introduced that will
trigger validation without saving to allow programmers to do early
validation if they need to.
All this with bonus points for keeping an internal flag on the object
that tells wether this object is "validated" or "dirty" with
__setattr__ (or actually property access) automatically marking objects
as "dirty", so that the implicit .validate() within .save() isn't
needed if early validation was used. """
>From my perspective this proposal is clean, and provides some
flexibility for the developer.
It may be worthwhile to look at how Rails approaches this problem as a
source of ideas:
(http://www.onlamp.com/pub/a/onlamp/2005/10/13/what_is_rails.html?page=3)
--Nick
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
