Hello! I'm really happy that I've been accepted as a Google Summer of Code student. I will work at revamping validation framework and merging django-secure this summer. I created this thread to start discussion (especially about public API) and get some feedback as well as to share progress. Any comments are welcomed!
You can find my proposal as a gist here [1], but I'm going to describe my ideas in short here. [1] https://gist.github.com/chrismedrela/82cbda8d2a78a280a129 My proposal consists of two parts: the first one is revamping validation framework. Don't be confused with form validation - I mean validation of (mainly) apps and models triggered before launching server (or directly by `python manage.py validate` command). The main drawback of the existing framework is that it's monolithic and therefore hard to customize. The second part of my project is merging django-secure using the new refactored framework. That will be a proof that the framework is customizable. Let's start with validation. The validation is done every time you run your Django application. It prevents from misconfigurations (for example missing `upload_to` attribute of FieldFile) or invalid models (a model with a `id` field without `primary_key` set to True). Some apps need custom validation, for example admin app need to check all registered ModelAdmin instances. The new validation framework will cover some other use cases. For example, your apps will be able to check dependencies. Let's start with validating a field. Consider existing FieldFile field. It requires an `upload_to` attribute. How could you check if it's set using the new framework? class FieldFile(Field): (... lots of stuff ...) def validate_upload_to(self): if not self.upload_to: yield Error(obj=self, msg="required 'upload_to' attribute", explanation="Django need to know the directory where uploaded files should be stored.", hint="Add \"upload_to = 'path/to/directory/on/server'\" to model %(model)s in file %(model_file)s.") All methods starting with `validate_` will be called automagically at validation stage. You don't have to trigger it manually. The methods shouldn't have any parameters (excluding `self`). They should return list of errors and warnings or they should yield each of them (like in the example). You can see a new `Error` structure with the following fields: `obj`, `msg`, `explanation` and `hint`. The last two attributes are separated from `msg` in order to force Django developers to give its users really useful, user-friendly error messages with a list of solutions and explanation of a problem. I think that Django should be an intelligent framework that make a conversation with its users. The new framework will introduce a concept of warnings which are really similar to errors expect that they allow you to run server. A warning have the same fields: `obj`, `msg`, `explanation` and `hint`. Warnings will be used while merging django-secure. Not only fields can be validated, but also: models, managers and apps. In case of models, a developer has to write a *class method*, because we validate a model which is a class, not an instance. In case of apps, you can create `validation.py` file which should contain functions. After refactoring validation framework, I will focus on merging django-secure. django-secure is a set of tests improving security of django applications. I won't implement new features, that would be only fitting it to the new framework. I will publish proposal of its new public API in the future. Feel free to comment and criticize! -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
