newforms-admin FormSet API

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

newforms-admin FormSet API

Brian Rosner

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.

[1]: http://dpaste.com/hold/51750/

Brian Rosner
http://oebfare.com




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: newforms-admin FormSet API

Russell Keith-Magee-2

On Wed, May 21, 2008 at 5:56 AM, Brian Rosner <[hidden email]> 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 %-)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: newforms-admin FormSet API

Honza Král
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
<[hidden email]> wrote:

>
> On Wed, May 21, 2008 at 5:56 AM, Brian Rosner <[hidden email]> 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: [hidden email]
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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: newforms-admin FormSet API

Joseph Kocherhans
In reply to this post by Russell Keith-Magee-2

On Wed, May 21, 2008 at 8:44 AM, Russell Keith-Magee
<[hidden email]> wrote:
>
> 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?

Brian and I both tried to come up with a class based syntax to take
care of formsets, but everything we came up with felt forced... like
we were *just* doing it as an attempt at consistency. Our attempts
actually made the implementation worse. This is one of the reasons
Brian wrote the email though. If someone wants to propose a class
based syntax, please do so. I'd love to see something better, and I
have a hunch that there *is* a better way. I've been sitting on it for
a few months now, and nothing has come to me. I'm probably too close
to the problem though.

For the record, it was just form_for_instance that I really wanted to
see destroyed... form_for_model is actually pretty useful in some
cases. You'll notice that there's no _for_instance analogues in the
API ;)

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

Indeed. That might be a "not ready for primetime" feature right now.
It doesn't work with models yet, and it might be better to provide a
field class, or a widget for ordering and deletion.

Joseph

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: newforms-admin FormSet API

Russell Keith-Magee-2

On Thu, May 22, 2008 at 12:06 AM, Joseph Kocherhans
<[hidden email]> wrote:

>
> On Wed, May 21, 2008 at 8:44 AM, Russell Keith-Magee
> <[hidden email]> wrote:
>>
>> 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?
>
> Brian and I both tried to come up with a class based syntax to take
> care of formsets, but everything we came up with felt forced... like
> we were *just* doing it as an attempt at consistency. Our attempts
> actually made the implementation worse. This is one of the reasons
> Brian wrote the email though. If someone wants to propose a class
> based syntax, please do so. I'd love to see something better, and I
> have a hunch that there *is* a better way. I've been sitting on it for
> a few months now, and nothing has come to me. I'm probably too close
> to the problem though.

I might not be close enough to the problem, but it seems to me that
you are already 90% of the way there with one of your examples. In the
sample docs, you have an example of extending a 'BaseFormSet' to add a
clean method:

class BaseArticleFormSet(BaseFormSet):
     def clean(self):
         raise forms.ValidationError, u'An error occured.'

ArticleFormSet = formset_factory(ArticleForm,
formset=BaseArticleFormSet, extra=2)

Is there any particular reason that you can't just add a Meta class to
this class definition, in the same way that a ModelForm works:

class ArticleFormSet(FormSet)
    class Meta:
        form = ArticleForm
        extra = 2
        can_delete = True

    def clean(self):
        raise forms.ValidationError, u'An error occured.'

I'm guessing InlineFormSet and ModelFormSet will need their own meta
class processing to handle their specific options, but there should be
a lot of common code between them.

Yours,
Russ Magee %-)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: newforms-admin FormSet API

Giovanni Dr. Chiozza

DO NOT SEND ME ANY MESSAGGE PLEASE !!

----- Original Message -----
From: "Russell Keith-Magee" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, May 27, 2008 1:33 PM
Subject: Re: newforms-admin FormSet API


>
> On Thu, May 22, 2008 at 12:06 AM, Joseph Kocherhans
> <[hidden email]> wrote:
>>
>> On Wed, May 21, 2008 at 8:44 AM, Russell Keith-Magee
>> <[hidden email]> wrote:
>>>
>>> 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?
>>
>> Brian and I both tried to come up with a class based syntax to take
>> care of formsets, but everything we came up with felt forced... like
>> we were *just* doing it as an attempt at consistency. Our attempts
>> actually made the implementation worse. This is one of the reasons
>> Brian wrote the email though. If someone wants to propose a class
>> based syntax, please do so. I'd love to see something better, and I
>> have a hunch that there *is* a better way. I've been sitting on it for
>> a few months now, and nothing has come to me. I'm probably too close
>> to the problem though.
>
> I might not be close enough to the problem, but it seems to me that
> you are already 90% of the way there with one of your examples. In the
> sample docs, you have an example of extending a 'BaseFormSet' to add a
> clean method:
>
> class BaseArticleFormSet(BaseFormSet):
>     def clean(self):
>         raise forms.ValidationError, u'An error occured.'
>
> ArticleFormSet = formset_factory(ArticleForm,
> formset=BaseArticleFormSet, extra=2)
>
> Is there any particular reason that you can't just add a Meta class to
> this class definition, in the same way that a ModelForm works:
>
> class ArticleFormSet(FormSet)
>    class Meta:
>        form = ArticleForm
>        extra = 2
>        can_delete = True
>
>    def clean(self):
>        raise forms.ValidationError, u'An error occured.'
>
> I'm guessing InlineFormSet and ModelFormSet will need their own meta
> class processing to handle their specific options, but there should be
> a lot of common code between them.
>
> Yours,
> Russ Magee %-)
>
> >
>


--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 269.24.1/1468 - Release Date: 26/05/2008
15.23


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: newforms-admin FormSet API

Gary Davis-4
In reply to this post by Russell Keith-Magee-2

I'm a Django newbie, so please pardon me if I am asking stupid
questions or raising issues long-solved,
but ...
I have some requirements similar to these that you are discussing for
'formsets', and maybe my experience can help a little..

I went ahead and built myself a  'formset' factory, of sorts, for my
application,
to meet the following requirements that I couldn't readily handle with
the existing newforms.ModelForm class (at least as re-worked by the
Google Apps team ... maybe the 'standard Django' code handles them
better):

1) forms to display/edit only some of the fields in a model
reasons:
1.1) multiple forms per page,for easier page layout (e.g. multiple
columns)
1.2) multiple edit pages per object - e.g. "wizard" editing
2) display-only fields
reasons:
2.1) display, but not change, 'derived fields', such as 'slugified'
fields, date-updated, etc.
2.2) edits restricted by business logic, such as only allowing a
supervisor to change a selling price in a retail store application

I just took a quick look at your 'formset', at
  [1]: http://dpaste.com/hold/51750/
and I see that it supports (my 1.1) multiple-forms-per-page
I also found:
  http://www.djangosnippets.org/snippets/758/
which supports (my 2) display-only fields.
I like that: will anything like it get into 'base Django'?

I took a brief look at this:
  http://www.djangoproject.com/documentation/form_wizard/
but I didn't like the concept of shuffling all of those hidden fields
back and forth.

If any of my requirements, or concepts, or code, would be of help,
please let me know how I can contribute something

Here's my application:
http://froi.gawsh.net
It does data entry for a Workers Compensation claim, and it gathers
100 to 300 fields through a 'wizard'-style interface.
It's running on the Google App Engine, so it's using Django templates
but, of course, uses the Google datastore.
If you can spare the time, please take a look at it and send me any
comments.

Should I be looking at any other documentation, or code, that you are
developing?

Thanks for any advice you may have,
Gary Davis


On May 27, 4:33 am, "Russell Keith-Magee" <[hidden email]>
wrote:

> On Thu, May 22, 2008 at 12:06 AM, Joseph Kocherhans
>
>
>
> <[hidden email]> wrote:
>
> > On Wed, May 21, 2008 at 8:44 AM, Russell Keith-Magee
> > <[hidden email]> wrote:
>
> >> 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?
>
> > Brian and I both tried to come up with a class based syntax to take
> > care of formsets, but everything we came up with felt forced... like
> > we were *just* doing it as an attempt at consistency. Our attempts
> > actually made the implementation worse. This is one of the reasons
> > Brian wrote the email though. If someone wants to propose a class
> > based syntax, please do so. I'd love to see something better, and I
> > have a hunch that there *is* a better way. I've been sitting on it for
> > a few months now, and nothing has come to me. I'm probably too close
> > to the problem though.
>
> I might not be close enough to the problem, but it seems to me that
> you are already 90% of the way there with one of your examples. In the
> sample docs, you have an example of extending a 'BaseFormSet' to add a
> clean method:
>
> class BaseArticleFormSet(BaseFormSet):
>      def clean(self):
>          raise forms.ValidationError, u'An error occured.'
>
> ArticleFormSet = formset_factory(ArticleForm,
> formset=BaseArticleFormSet, extra=2)
>
> Is there any particular reason that you can't just add a Meta class to
> this class definition, in the same way that a ModelForm works:
>
> class ArticleFormSet(FormSet)
>     class Meta:
>         form = ArticleForm
>         extra = 2
>         can_delete = True
>
>     def clean(self):
>         raise forms.ValidationError, u'An error occured.'
>
> I'm guessing InlineFormSet and ModelFormSet will need their own meta
> class processing to handle their specific options, but there should be
> a lot of common code between them.
>
> Yours,
> Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: newforms-admin FormSet API

Brian Rosner
In reply to this post by Russell Keith-Magee-2

On 2008-05-27 05:33:01 -0600, "Russell Keith-Magee"
<[hidden email]> said:

> Is there any particular reason that you can't just add a Meta class to
> this class definition, in the same way that a ModelForm works:
>
> class ArticleFormSet(FormSet)
>     class Meta:
>         form = ArticleForm
>         extra = 2
>         can_delete = True
>
>     def clean(self):
>         raise forms.ValidationError, u'An error occured.'
>
> I'm guessing InlineFormSet and ModelFormSet will need their own meta
> class processing to handle their specific options, but there should be
> a lot of common code between them.

I made an attempt to normalize the API in 6241 [1]. That is where we
decided that it was really complicating things. It may have been in my
implementation itself. I am still not opposed to doing some sort of
normalization, but at this point not sure how to go about simplifying
the implementation.

[1]: http://code.djangoproject.com/ticket/6241

--
Brian Rosner
http://oebfare.com



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: newforms-admin FormSet API

Brian Rosner
In reply to this post by Gary Davis-4

> Should I be looking at any other documentation, or code, that you are
> developing?

Yes. What you have brought up is actually not the use case for
formsets. However, you do bring up something that makes me want to
clarify in the docs a bit more. When I say multiple forms per page,
that really doesn't mean having fields from N models that are grouped
together in some fashion and presented in different locations on the
page to make it more user friendly. What it really means is having
multiple Form/ModelForm objects that are equivalent in fields and bound
to some list dataset. Just like the edit_inline functionality found in
the admin. All your other issues deal directly with newforms yourself.
I would give the newforms and modelforms documentation again.

newforms: http://www.djangoproject.com/documentation/newforms/
modelforms: http://www.djangoproject.com/documentation/modelforms/

--
Brian Rosner
http://oebfare.com



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---