Model validation outside of ModelForms.
Gerry
Has there been any discussion about enforcing model validation on
models
without using ModelForms? I really like the new Model validation but I
don't
like (nor think its very DRY) to override the save method for all of
my models
to just call full_clean(). It would be nice if there was someway I
could enable
validation by default. Currently I use a Meta option that when set to
True will
will have Model.save() call full_clean().
Many thanks to all involved with model validation and getting it into
trunk,
great work everyone!
Gerry
orokusaki
It doesn't seem that the core team is interested in working on Model
validation at the moment: http://code.djangoproject.com/ticket/13121
(my failed ticket)
The current thinking by the powers that be is that you cannot
introduce model-level validation enforcement without breaking the API
for existing users. This is simply not true.
With ValidationError propagating upwards from the model level,
ModelForm would need nothing to do with validation besides displaying
the errors to the user. This is the common sense approach to
ModelForms anyway, and the only people who would suffer from this
migration would be those who have hacked the core from within their
code (re-writing methods in their subclasses that shouldn't typically
be re-written).
If this were the case, you could build all of your data logic into the
Model and then an RPC API, a view, or the built-in Admin would all be
very DRY and work identically when using your model. Instead you have
to rewrite code all over the place and you cannot even abstract
correctly as their are too many leaks into the view layer (see
http://www.joelonsoftware.com/articles/LeakyAbstractions.html).
Michael
James Bennett
> It doesn't seem that the core team is interested in working on Model
> validation at the moment: http://code.djangoproject.com/ticket/13121
> (my failed ticket)
Stop right there and actually go back and *read* all the feedback
you've gotten, because right now you're just flat-out lying. Russell
has, on multiple occasions, asked you, begged you, and pleaded with
you to get proper discussion going on the things you've proposed.
You've refused and instead adopted a method of opening duplicate
tickets and screwing around with the metadata on existing ones,
apparently out of a desire to annoy as many people as possible rather
than get anything useful done.
If you'll actually pay attention to what others say and actually put
in the time to learn how the Django development process works, you may
be a lot happier with the results. If instead you just continue what
you've been doing, well, I for one will be happy to direct you to some
other framework that's willing to put up with such antics.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Harro
save signal to call the full clean method?
Dunno if that will work or not, just the first thing I would try.
On Mar 16, 5:12 pm, James Bennett <ubernost...@gmail.com> wrote:
orokusaki
On Mar 16, 10:12 am, James Bennett <ubernost...@gmail.com> wrote:
Actually I'm not lying. Russell hasn't given me any feedback regarding
my idea or patch. I didn't simply reopen tickets. Russell changed my
ticket to a documentation ticket, so I opened a new ticket to discuss
that which he avoided in his discussion. This kind of ego-driven
closed mindedness is probably why Django has a low rated community for
being such a popular framework. If one person could give me a good
(non-formality related) reason for Russell to dismiss my ticket in
aprox 2.5 minutes, I would stop complaining about it. It isn't because
of OCD that I want this bug fixed. It is because it won't break
compatibility, it takes about 5 minutes, and it adds so much value
(with respect to its simplicity).
orokusaki
On Mar 16, 10:16 am, Harro <hvdkl...@gmail.com> wrote:
> Just my brainfart when looking at this: Can't you simply add a pre
> save signal to call the full clean method?
>
> Dunno if that will work or not, just the first thing I would try.
>
> On Mar 16, 5:12 pm, James Bennett <ubernost...@gmail.com> wrote:
>
Hey James, I've not used signals yet so I don't know where they fit in
the control flow. My first guess is to say no it wouldn't work because
I couldn't imagine that pre_save would be called while ModelForm was
listening for ValidationErrors. This would be hackish IMHO also, but
I'll give it a try though when I get back to my comp (on phone).
James Bennett
> Actually I'm not lying. Russell hasn't given me any feedback regarding
> my idea or patch. I didn't simply reopen tickets. Russell changed my
> ticket to a documentation ticket, so I opened a new ticket to discuss
> that which he avoided in his discussion.
As you've been told now, multiple times:
Discussion of feature design and other high-level work does not take
place in Trac. Trac is good at organizing bugs and keeping tabs on
patches and status, but absolutely terrible at that sort of high-level
discussion. Thus, such discussion takes place here, on a mailing list
well-suited to the task. This is not "ego-driven closed mindedness",
this is simple practicality; it's the way things have to work in order
for them to work at all. And it's incredibly easy to do; in the time
you've spent opening and reclassifying tickets to try to get what you
want, you could've accomplished your stated goal -- getting discussion
and feedback on your proposal -- a dozen times over. Instead all
you've done is waste developer time and annoy people.
And just by way of official warning: if you decide to ignore this and
just continue on as you have been, you may leave the dev team with no
choice but to show you the door. We're short enough on developer time
already, and we can't afford to stop and go over basic things like
this multiple times (let alone doing so while you sit back and sling
insults at us).
James Bennett
> without using ModelForms? I really like the new Model validation but I
> don't
> like (nor think its very DRY) to override the save method for all of
> my models
> to just call full_clean(). It would be nice if there was someway I
> could enable
> validation by default.
The problem with this is that it can't really be generalized. One of
the reasons why ModelForm has the implementation it does is that often
you have a form which doesn't contain all the fields from the model,
or a view which uses the form for initial validation, then does
further work before finally saving a complete, valid object.
Similarly, being at the stage of calling save() doesn't necessarily
mean that the object is complete and valid; one common example is
default values, which won't yet be filled in when your custom save()
method tries to validate the object, resulting in a validation failure
even though the object *would* be valid by the time it hit the
database.
Developing an "automatic" validation option which is both simple
enough to actually be useful and robust enough to handle all the edge
cases is -- if it's even possible -- far more than can be accomplished
on the 1.2 timeframe. Hence, for now, Django doesn't have any such
thing, and won't have it in 1.2. If you think you can make it work for
1.3, your best bet is to work up a proposal, including at least some
sample code, along with an explanation of how you'll keep it both
simple and robust.
orokusaki
I'll focus on this here and see what I can come up with.
Michael