Moritz Sichert

As I already mentioned in #27, I really dislike how accessing `form.errors` in Django currently triggers a full validation (or clean). I agree that separating cleaners and validators makes sense...

Here is a list of what should be possible: - field validation (e.g.: username must not contain special characters) - field "cleaning" (e.g.: unicode-normalize username) - cross field validation (e.g.:...

Maybe sorting alphabetically is better here to make it less biased.

The need to serialize rich objects will definitely arise but I don't think that should be the job of a serializer (i.e. a thing that converts a simple, almost dict-like...

Yes, I guess the reducer would actually be a simple renderer itself. So you would then have something like: ``` +------------+ +------------+ rich data ---> | reducing | ---> simple...

`Widget.value_from_datadict()` and `Widget.render()` should also be mentioned here. That would be specific to an HTML serializer, though.

We're not sticking to HTML forms at all, in fact we thought about it to be exactly as you described it: Just another rendering options besides JSON or other formats.

I need a decision here. Should identity "addresses" treated as real addresses? Because right now they get mixed up heavily. If yes, we need to generalize the Address class a...

These are some really well thought proposals! But I have some questions and suggestions: - What exactly does `writer_ignore_interface` do? Does that just mean that the reader/writer gets called without...

I don't totally grasp the (old) router system, yet. Why exactly is it necessary to distinct between Clients and Jacks? Or is this just a thing that will become obsolete...