Progress: I've implemented manager checks.

The schedule for the next 4 weeks is:

1. Manager checks (ref 4.1.7)(done)(0.5 week).
2. Entry point registering (ref 4.1.5) & rewriting mechanism of triggering
   checking framework (ref 4.1.9)(1.5 week).
3. Moving custom User model checks (ref 4.1.6)(0.5 week).
4. Rewriting AdminModel checks and tests (ref 4.1.8)(1 week).
5. Polishing doc (ref 4.1.10)(0.5 week).

(ref 4.1.x are references to my original proposal [1])

[1] https://gist.github.com/chrismedrela/82cbda8d2a78a280a129)

Let's talk about public API to register your own validation stuff. There 
will
be `register(callable)` function in `django.core.checks`. It will return
nothing. The callables will be stored in a global variable. They should obey
the same contract as `check` methods: they allow for `**kwargs` and return
list of errors and warnings. All registered callables will be called during
checking phase (i. e. when you type `manage.py validate` or before running
server).

This API allows us to register, among other things, app-specific checks. But
it's not necessary to write an app in order to do some checks.

`register` function will have two optional parameters: `run_in_production`
(default: False) and `run_in_development` (default: True) that let you 
specify
when the callable should be called. Most checks should be performed only in
development environment (which is equivalent to DEBUG==True). Security 
checks
makes sense only in production environment (<==> DEBUG==False).

I would be happy if I could hear your opinion!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to