On Aug 23, 2006, at 6:25 PM, Adrian Holovaty wrote:
> Let's make this happen!
Indeed!
I've got some thoughts and preferences given all the ideas I've seen,
so here goes... Essentially, I think there's two tasks here:
1. Validation-aware models.
I very much want to be able to validate and save models without the
use of manipulators (or forms or whatever you call 'em). I'd like to
be able to do something like::
p = Person(**data)
try:
p.save()
except ValidationError:
handle_the_error()
The ``Model.validate()`` method that Adrian's started on should
handle this, and also nicely allows models to define custom
validation behavior outside of the manipulator framework (by
extending that ``validate()`` method).
One issue that's been raised is that ``p.save()`` could potentially
raise many validation errors, and ideally those would be communicated
up the extension stack. So probably we'd need a ``ValidationErrors``
exception that encapsulates a bunch of validation errors in a single
exception. ``Model.save()`` could raise one of these, and I'd
imagine that ``Model.validate()`` would do the same.
I think we're well on our way towards making this work. We'd need to
complete the various field-level validation, and then make it active.
2. Simplify forms, and make the word "Manipulator" go away.
Like Adrian, I can't stand the word :) It's just so... Java-ish.
The other thing I can't stand is the whole FormWrapper layer over
Manipulators; ideally the replacement would merge the two.
I quite like Joseph's proposal. I especially like being able to
control which form is used both for generic views and in the admin.
I'm also a fan of the {{ form.html }} shortcut. With some careful
use of nice semantic HTML we should be able to make that shortcut
work nearly all the time.
I'm less hot on the view syntax from Joseph's proposal; it still
seems like more steps than I'd like to use.
Brant's proposal also has some high points; in particular, the
separation of converting data from its POSTed representation is
something that we need to get right; making it an explicit step is
the right way to go.
However, this::
except Form, form:
*really* rubs me the wrong way. To me, this is a pretty counter-
intuitive use of exceptions -- exceptions should be used to indicate
an exceptional situation; not an expected one. Furthermore, PEP 352
(http://www.python.org/dev/peps/pep-0352/) -- which will be complete
in Python 3.0 - requires that exceptions actually extend from
``BaseException``, which introduces weird semantics all its own. I'm
a big -1 to using exceptions for Forms.
So, given all that, I think we ought to use Joseph's proposal as a
starting point, but integrate a few ideas from what Brant came up
with. In particular, here's how I'd add to/change Joseph's outline:
- Add an explicit ``convert()`` step to the ``Form``. It would be
called automatically, but making the step separate would allow
subclasses to override it if necessary, and would also allow code
just convert data (a need I've seen in a few places).
- Figure out a way to make the common-case view code as simple and
streightforward as possible. I'm not sure where to go here, but I
think we can improve on Joseph's idea a bit.
Al-rightly then... thoughts?
Jacob
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
