WTForm is simple implementation built on top of existing (new)forms to
help create fieldsets, and by judging django snippets alone one can
see it's a huge hole in Django. Everyone has wondered why the heck
doing those fieldsets is such a pain when in admin it is super easy,
and it turns out the Django admin's way is unusable in elsewhere.
Thats the way I ended up doing my own fieldset implementation long ago
to ds, but as usual it went unmaintained.
When I had lost all will to Django ever implementing this, someone had
redone something similar, WTForm http://www.djangosnippets.org/snippets/214/ (unmaintained) with more care on details. Though it also went
unmaintained until akaihola took it to his care:
The maintained version could be added to Django, and start refactoring
parts of Django to make use of it. I mean Django admin should
definitely use this WTForm somehow, it is way more DRY than the one in
place now for the Fieldsets.
I really hate to be a pessimist, but if the functionality already
exists for that much generation, why bother integrating it with the
main django package?
On Mar 18, 8:06 pm, Jari Pennanen <jari.penna...@gmail.com> wrote:
> WTForm is simple implementation built on top of existing (new)forms to
> help create fieldsets, and by judging django snippets alone one can
> see it's a huge hole in Django. Everyone has wondered why the heck
> doing those fieldsets is such a pain when in admin it is super easy,
> and it turns out the Django admin's way is unusable in elsewhere.
> Thats the way I ended up doing my own fieldset implementation long ago
> to ds, but as usual it went unmaintained.
> When I had lost all will to Django ever implementing this, someone had
> redone something similar, WTFormhttp://www.djangosnippets.org/snippets/214/ > (unmaintained) with more care on details. Though it also went
> unmaintained until akaihola took it to his care:
> The maintained version could be added to Django, and start refactoring
> parts of Django to make use of it. I mean Django admin should
> definitely use this WTForm somehow, it is way more DRY than the one in
> place now for the Fieldsets.
On Wed, 2009-03-18 at 17:06 -0700, Jari Pennanen wrote:
[...]
> I wish people has some thoughts about this...
Well, one thought is that your timing is a little off. We're in the final phases of getting the 1.1-beta release out and then it's heads down, fixing bugs for 1.1-final.
In a couple of months or so we'll be having a discussion for proposals to include in Django 1.2. That would be an excellent time for somebody to bring this up -- and it probably should be akaihola, since we don't want to conscript projects into the tree unwilling.
Having just had a quick read fo the source -- this is the first time I've heard of the project -- it looks well enough written. Akaihola does know his stuff; we already know that. Possibly we wouldn't pull in the whole project, but get a patch to add the fieldsets capabilities.
I suspect, though, that adding fieldsets to forms isn't hard at all. We just need a decent API proposed and a short patch to implement it. The work in WTForms looks like an approach at creating one such API (since there are neither docs nor tests, I'm reverse-engineering the API from the code in my head, but it looks pretty decent). So the real discussion is probably about an API.
When/if that happens, of course we'll use it internally in Django where appropriate.
If anyone else read this and was as confused as I was at first, make
sure to note that this is different than WTForms[1], which is an
alternate form library that took several of its cues from Django's
newforms.
> WTForm is simple implementation built on top of existing (new)forms to
> help create fieldsets, and by judging django snippets alone one can
> see it's a huge hole in Django. Everyone has wondered why the heck
> doing those fieldsets is such a pain when in admin it is super easy,
> and it turns out the Django admin's way is unusable in elsewhere.
> Thats the way I ended up doing my own fieldset implementation long ago
> to ds, but as usual it went unmaintained.
On 19 maalis, 02:24, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> Having just had a quick read fo the source -- this is the first time
> I've heard of the project -- it looks well enough written. Akaihola does
> know his stuff; we already know that. Possibly we wouldn't pull in the
> whole project, but get a patch to add the fieldsets capabilities.
It's not my original code. I pulled Christian Joergensen's project
from pypi into my GitHub account so I could update and use it with
Django 1.0. I've now made that more clear in the GitHub description.
My only contributions so far are fixing the newforms import and
importing past releases into a git repository.
After playing with WTForm a bit it became clear that it wasn't
flexible enough for the task at hand at that time, so I created all
HTML manually instead in that project. As I'm not using WTForm in any
of my projects, I don't currently have an incentive to maintain
WTForm.
akaihola wrote: >> Having just had a quick read fo the source -- this is the first time >> I've heard of the project -- it looks well enough written. Akaihola does >> know his stuff; we already know that. Possibly we wouldn't pull in the >> whole project, but get a patch to add the fieldsets capabilities.
> It's not my original code. I pulled Christian Joergensen's project > from pypi into my GitHub account so I could update and use it with > Django 1.0. I've now made that more clear in the GitHub description.
> My only contributions so far are fixing the newforms import and > importing past releases into a git repository.
First of all; great work taking the initiative of updating WTForm to Django 1.0.
> After playing with WTForm a bit it became clear that it wasn't > flexible enough for the task at hand at that time, so I created all > HTML manually instead in that project. As I'm not using WTForm in any > of my projects, I don't currently have an incentive to maintain > WTForm.
Other than fieldsets I really believe adding CSS class attributes to the parent HTML markup (<tr>, <p> or <li> that is, depending on the rendering) containing the field type, the widget and a required flag would ease the work of web designers a lot. I know it has helped our web designer a lot.
On Jun 20, 12:13 pm, Andre Terra <andrete...@gmail.com> wrote:
> Have we moved forward with this issue at all? What is its current status?
I also maintain an external package that implements fieldsets (django-
form-utils [1]). Both django-form-utils and WTForm take the approach
of adding a Python data structure to Form.Meta that represents the
fieldsets. At one point I had thought I would push a patch to get a
fieldsets API like this into django.forms, but I'm no longer convinced
that's a good plan.
For the admin, representing fieldsets in a Python data structure in
the ModelAdmin is necessary and appropriate, since the admin is auto-
generating form rendering for a wide variety of Python models, and a
Python programmer should be able to generate these fieldsets by
touching only Python code. That's a special case. In general,
rendering of forms with fieldsets is a purely presentational issue
(the fieldsets don't impact the data submitted by the form), so I
think having fieldsets represented in Python code is the wrong
approach (and will inevitably lack the flexibility the designer needs
in their markup, just like the current hardcoded form field rendering
does). A template author and designer should be able to make changes
to the markup presentation of a form, including fieldsets, without
needing to touch Python code at all.
Gregor Müllegger is currently working on a Google Summer of Code
project to provide a templates-based flexible form rendering system. I
think this system will be flexible enough to allow template authors to
use fieldsets with forms easily and non-repetitively.
