On 11/10/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > On 11/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > I'd hate to see the obj arg get put into the constructor of a > BaseForm, so Form's metaclass would end up generating a subclass of > BaseForm or BaseModelForm depending on whether or not the Form had an > inner Meta class (or whatever we call it). The implementation of the > ModelForm syntax seems cleaner to me, but there's most likely a better > way to implement your syntax that I haven't thought of.
I haven't given much thought to the implementation either. If there is an objection to having the instance in the argument list of for the BaseForm constructor, modifying the base class certainly sounds like one option. However, I can't say I have a problem with allowing an instance to be provided as initial data. This would essentially allow you to manually construct a form for an instance, while retaining many of the 'instance bound' benefits of a ModelForm. This also supports the idea that the Meta block is just a set of assembly instructions. The form is just a collection of fields that can be populated (however the fields were constructed), and one source of initial data for those fields is an instance. The problem I have with ModelForm is that it doesn't feel like it has any parallels with the existing class-based formdefinitions. Manual Form definitions have a very similar flavour to Model definitions - each class attribute is a part of the model/form, etc. On one level, ModelForm tries to follow this lead by using a class-based syntax and allowing save() and clean() methods - but then it has a completely different approach to defining form fields, etc. In contrast, form_for_* doesn't looks anything like a manual form definition, so it's obvious that you're dealing with a different beast. > The whole idea of a formfield callback is powerful, but it really > lacks in readability for the common tasks of specifying custom widgets > and excluding specific fields. Agreed. I would also add dynamically modifying the list of choices in a Select to this list of deficiencies. Russ %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
