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 -~----------~----~----~----~------~----~------~--~---