I've been working on something almost identical to this. But your formconfig is
what really gives it that last piece that I didn't have, very nice!
I doubt that it's helpful, but I just put my code up at:
https://github.com/bunchesofdonald/django_amaro it's still very early stages,
and needs cleaned up, etc. I was just trying for a proof of concept.
Let me know if you need another developer and I'll be there, this is one of my
biggest pain points with Django.
Chris
On Jun 23, 2011, at 7:25 AM, Idan Gazit wrote:
> At DjangoCon Europe 2011, Gregor Müllegger gave a great lightning talk about
> his work on a revised form rendering API:
>
> http://www.scribd.com/doc/57270484/Djangocon-EU-2011-Revised-Form-Rendering-Lightning-Talk-by-Gregor-Mullegger
>
> I sat down with Gregor, Jannis, Russell, Alex, Ericflo, Andrew Godwin, and
> many other fine minds at the sprints to think about his proposal and help
> refine it. At the risk of starting a bikeshedding war, I'd like to share the
> results of the sprints and get some feedback on our proposed approach.
>
> I'm very pleased with the resulting API. It has one significant wart, but
> having chewed on the alternatives, I think there is consensus that this API
> represents a good compromise between purity and practical considerations.
>
>
> # Goals
>
> The existing rendering facilities for forms aren't bad, but they suffer from
> the following drawbacks:
>
> 1. All-or-nothing: if you'd like to customize one small part of form
> rendering, you have to go the whole hog and write out a ton of boilerplate.
> 2. "Frontend developers need not apply": large parts of form rendering happen
> in Python. If a frontend dev wants to customize certain aspects of
> form.as_p's output, they've got to bust out the python.
> 3. Prevents modularity and code re-use: with large bits of markup locked
> inside .py files, it's difficult for designers to share reusable form
> patterns.
> 4. DOCTYPE lock-in: designers are forced to use the XML style of tags,
> breaking validation of other doctypes when forms are present.
>
> The new form rendering API addresses these drawbacks, and as such, has the
> following desirable properties:
>
> 1. No backwards-incompatible changes: the new API coexists peacefully with
> the old one, allowing for a smooth transition and deprecation of the old
> formrendering API.
> 2. Simple beginner usage: if all you're comfortable using is {{ form.as_p }},
> the new API retains a similarly brief approach.
> 3. Vastly better customizability: the new API provides an expressive and
> flexible means for specifying how forms should be rendered, and allows you to
> override just the parts that need changing.
> 4. Significant improvements to the rendering of form rows with multiple
> fields (for example, first and last name, or credit card and expiration).
> 5. Dogfooding: the new API does have some new tags, but a lot of the
> internals and examples for customization are just using the existing template
> system. This provides a lot of flexibility, but it also means that the new
> API should feel familiar to existing developers.
> 6. Modularity: it will be possible to produce reusable libraries of form
> rendering templates.
>
>
> # The anatomy of form rendering templates
>
> Forms are composed of three logical units:
>
> 1. A template which represents the form itself, including some form-specific
> configuration.
> 2. A template which represents a given "row" in a form. A row is an abstract
> concept, and doesn't have to represent a horizontal slice of anything (but
> usually does). The existing form rendering API produces rows in the shape of
> 's, 's, and 's. In the new form rendering API, Django supplies the
> formrow templates for all three of these row "types", but users can easily
> add new ones of these to create a formrow based on 's, for example.
> 3. A template which represents a given widget in the form. These are the
> widgets which are currently provided by the framework, but supplied as
> templates instead of being buried in widgets.py.
>
> # Examples.
> I've prepared example templates for each of these; check out
> https://github.com/idangazit/formrendering after reading the following
> tutorial. These represent a good starting point for developing the form
> templates distributed with Django.
>
> # API Usage Tutorial
>
> The new API introduces the following template tags:
>
> - form
> - formconfig
> - formrow
> - formfield
>
> For the following examples, "myform" is a form instance present in the
> template's context.
>
> # {% form %}
>
> The new form rendering API introduces a {% form %} tag:
>
> {% form myform %} {# equivalent to the following line #}
> {% form myform using "forms/layouts/table.html" %}
> {% form myform using "forms/layouts/p.html" %}
> {% form myform using "forms/layouts/ul.html" %}
>
> In its simplest incarnation, it works like the existing form.as_XX
