I don't have particularly strong feelings about this, with the exception
of a few things noted below...
On Thu, 2008-10-16 at 20:09 -0700, pm13 wrote:
> I would like to propose five quite isolated improvements for
> django.forms. But I think it is better to write about them in one
> email - otherwise there would not be complete answers for the
> problems. (More specifically, proposal 5 is very useful for proposals
> 1 and 2. And proposals 3 a 4 are very useful for proposal 5). And the
> improvements have common motive - it should be very easy to write very
> powerful and very flexible forms.
>
> I want only write about syntax. I have working patches for them but I
> don't say they are perfect or ready (for example only the first of
> them has tests).
>
> 1. Ordering and filtering of fields, fieldsets
As a general note: Ordering really only makes sense for subclassing,
when you might apparently want to insert a new field in a particular
place in the existing fields' lists. I wouldn't want to put a lot of
effort into allowing changing the ordering of an existing form's fields,
since why wasn't the form created with the right order in the first
place. Creating a form is so easy, that micro-tweaking like that
shouldn't be necessary. Realise that changing the ordering of fields
actually slightly changes the validation, since a clean_FOO method might
no longer have some other field coming ahead of it in the cleaning
process.
I also would, as a general rule, prefer to avoid adding yet more Meta
inner classes to things. They really mess around with stuff like
subclassing and overriding and, if we can avoid them, better to do so.
Fieldsets are the only case where they appear to be unavoidable, though
(exluding fields and altering ordering can already be done fairly easily
and they shouldn't be that common that adding lots of infrastructure to
support them would be necessary in core). But I can't see any great API
alternative for fieldsets at the moment.
[...]
> 2. Inlines
>
> There would be a new meta attribute for Form - inlines. And it would
> be possible to use inline in meta attribute fieldsets:
>
> class FormX(FirstForm, SecondForm):
> class Meta:
> fields = 'first_A', 'first_B', 'second_A'
> inlines = InlineA, InlineB
>
> class FormZ(FirstForm, SecondForm):
> class Meta:
> fieldsets = (
> {'fields': ('first_A', 'first_B', 'second_A')},
> InlineA,
> InlineB,
> )
>
> (These examples are equivalent.)
>
> Attribute "inlines" would be a list of formset classes. And these
> classes could be a part of "fieldsets" attribute.
This I don't like. It's making Forms == Formsets at some level. Why are
you needing to use Forms to contain Formsets, instead of using Formsets
to contain Formsets? Formsets are made up from Forms, rather than
vice-versa. I'm not really understanding the use-case for this ("it's
another way to do it" isn't really a use-case). What's the problem
you're trying to solve here?
I realise you kind of avoid this confusion with the next paragraph...
> Form would not be able to construct inline formset instances.
> ModelForm would construct inline formset instances through one to many
> model fields.
... but it still feels like you're making something that is a Form
contain Formsets. Maybe the/a ModelForm constructor needs to optionally
return a proper Formset instead.
p,,,[
> 3. Meta attribute formfield_kwargs for model forms
>
> There would be a new meta attribute for ModelForm - formfield_kwargs.
> It is a generalization of the "widgets proposal":
I don't really like this one. You can already do this sort of stuff.
It feels like these proposals (not just this thread but other ones as
well) show that there are, in fact, many ways to work with forms. Since
they're all possible write now with a few helper methods, attempting to
add stuff to core to do the One True Way for forms would be fooling
ourselves. There just isn't a single right way here, or even an
obviously best way. So somebody will write and distribute MetaBaseForm
that can be used as a base class, somebody else will write
ExplicitWidgetForm that can be used as a base class, etc, and they all
can be done without core changes.
In general, I'm going to be against any radical changes in form
declarations because I just don't see any obvious winner yet and
experimentation is possible without core changes.
> 4. Attributes "attrs", "template" and "legend" for init methods in
> forms
Same argument as for the previous point. It's already possible just by
writing a base class that you subclass from instead of Form, so changes
to core shouldn't be necessary and it's not so clearly better than
alternative approaches to warrant inclusion in core as better than the
de-factor way to do things at the moment, to my mind.
I think you've got some interesting ideas, but I'm not sure they are
necessarily the easiest way to do things. We have to stop trying to
"solve" the forms issue and instead realise that what we have is
actually a very good base for the basic functionality. Wrapping
different APIs around that can then be done via subclasses and people
should definitely do that. It's exactly why forms don't need 47
different as_*() methods, for example, because if you need one of those
in particular, you write it in the common Form subclass that all you
specialised forms inherit from.
> 5. Contrib application with form templates
Definitely -1 here, just on the grounds that it's proposed for contrib
without having any real history behind it yet. Anything proposed for
contrib should already have a strong third-party following and history
of maintenance (with very, very few exceptions). So this should be
viable as an external application first before being included.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
