WTForm should be inbuilt to Django, and make admin & others use it.
Jari Pennanen
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:
WTForm *Maintained* by akaihola found here http://github.com/akaihola/django-wtform/tree/master
works with Django 1.0 supposedly.
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 wish people has some thoughts about this...
Joe Tyson
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
> unmaintained until akaihola took it to his care:
>
Malcolm Tredinnick
[...]
> 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.
Regards,
Malcolm
Eric Florenzano
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.
[1] http://wtforms.simplecodes.com/
Thanks,
Eric Florenzano
sime
akaihola
wrote:
> 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.
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.
All this said, I agree that fieldsets would be an appropriate addition
to the forms library. See also ticket #8272: http://code.djangoproject.com/ticket/8272
I'll try to pull Christian into this discussion as well.
Christian Joergensen
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.
That's kind of the point where I arrived at too.
> All this said, I agree that fieldsets would be an appropriate addition
> to the forms library. See also ticket #8272: http://code.djangoproject.com/ticket/8272
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.
http://www.technobabble.dk/2008/oct/09/hacking-django-forms-css-flexibility/
> I'll try to pull Christian into this discussion as well.
You succeeded :)
Regards,
Christian
--
Christian Joergensen
http://www.technobabble.dk
Andre Terra
Thank you in advance.
Sincerely,
André Terra
Carl Meyer
> Have we moved forward with this issue at all? What is its current status?
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.
Carl
[1] http://pypi.python.org/pypi/django-form-utils