Hi Brian, from our uses of the nfa, we found that these API are more than adequate for any use we could think of, which includes:
generic edit inlines custom validation if both forms and formsets added logic (including fields) in forms (even in forms used in inline formsets) and model creation (.save* on formsets and forms) The thing we bumped into was located elsewhere - with inline formsets. If you wish to override the default behavior when it comes to saving the object, you have to define the methods on the formset, which doesn't make much sense to me - the form itself would definitely be a more logical place where to do this. Other than this slight logical inconsistence (in my eyes), the API is VERY usable and allowed us to do everything we wanted without unnecessary fuss. Thanks very much for the great work. Honza On Wed, May 21, 2008 at 3:44 PM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On Wed, May 21, 2008 at 5:56 AM, Brian Rosner <[EMAIL PROTECTED]> wrote: >> >> Hello all, >> >> The newforms-admin branch is getting close to finalizing the formset >> API. However, to do so we would like to run it by the developer >> community for ideas. I have posted a diff [1] of documentation showing >> the API. The diff shows the API without a leading underscore on the >> factory functions. Meaning in source they are defined as: >> >> * _formset_factory >> * _modelform_factory >> * _modelformset_factory >> * _inlineformset_factory >> >> Joseph and I believe that just dropping the leading underscore will be >> good enough for a finalized API. What do others think of the API? My >> documentation writing skills are *not* to be criticized :P However, >> any errors or corrections to improve them would be greatly appreciated. > > I can't say I see a good reason for the underscore. They're public > documented methods, not part of private API. Underscore begone, I say! > > However, that said: I might be missing something here, but we've just > gone through the process of deprecating form_for_model and > form_for_instance based upon the reasoning that a class based form > definition is more flexible than trying to shoehorn everything into a > factory method. Is there a reason that we are introducing a new set of > factory methods rather than using a definition analogous to ModelForm? > To that end, isn't modelform_factory an analog of form_for_model? > > Regarding the docs - I'm sure Adrian will apply his magic pencil, but > as a first draft, it looks pretty good to me. One suggestion - the > 'can_order' option needs a little more elaboration on how the order > field can actually be used - i.e., how do I use the order field to > effect organization in my children? > > Yours, > Russ Magee %-) > > > > -- Honza Král E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
