\r\n

Nothing drastic has broken yet.

\r\n

Give us time :)

OK, not really drastic, but when newforms-admin lands on trunk a bunch of stuff will change, and Malcolm's Unicode work is going to hopefully make everybody quit bytestrings cold turkey (which, given where Python 3 is going, is good practice anyway).

Beginnings of the new documentation are [link|http://www.djangoproject.com/documentation/newforms/|here].

In a nutshell:

\r\n
• Manipulators were cumbersome to write, so a declarative metaclass has been introduced for specifying form fields. Form classes can now be declared in much the same way as models.
\r\n
• Separation of several concerns; there's now a "widget" layer which handles the actual HTML presentation, and allows you to interchangeably specify different widget types for different fields in the form class.
\r\n
• Easier usage; instead of the nasty copy-POSTdata-into-dict-and-validate stuff, you can now pass request.POST directly to a form, and forms have an is_valid method carries out validation for you on demand; you can then read known-good data out of the form's clean_data dictionary, which will also have the values converted to appropriate Python types (removing the need for do_html2python).
\r\n
• Custom validation methods can be declared as methods of the form class, taking their names from fields they validate; a clean_foo method will be called to validate the form field named foo, for example.
\r\n
• The internals of newforms work purely with Unicode strings, and we're moving toward having all of Django's internals do that to get out of the hell of "what encoding is this data in".
\r\n

So far I'm a big fan of it; I was able to whip up [link|http://django-registration.googlecode.com/svn/trunk/forms.py|a nice little user-registration form] without much code at all, as my first foray into newforms.

The integration into the admin is going to be the next big step; the admin app is getting heavily refactored to take full advantage of newforms and add a lot more flexibility (for example, you'll be able to easily override individual parts of the admin, with full access to the request to do more advanced permissions filtering).

The admin migration will involve some code changes because we're taking the opportunity to move admin definitions out of the model classes, but aside from that it's not a terribly difficult change to make, and code ends up a lot cleaner afterwards.