Opened 13 years ago
Closed 10 years ago
#16256 closed New feature (wontfix)
More class based views: formsets derived generic views
Reported by: | rasca | Owned by: | Asif Saifuddin Auvi |
---|---|---|---|
Component: | Generic views | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | rasca7@…, anton@…, GotenXiao, aaron@…, emyller@…, rh0dium, gerdemb, Trey Hunner, charette.s@…, hanne.moa@…, Markus Holtermann, dpwrussell, ville@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
This ticket aims to add more class based views to the generic ones provided by django.
I've implemented a FormSetsView, a ModelFormSetsView and a InlineFormSetsView.
Related django-dev thread: http://groups.google.com/group/django-developers/browse_thread/thread/6964432300ca0c6f/9aa1f1ea1ad16d81?lnk=raot&pli=1
Attachments (3)
Change History (40)
by , 13 years ago
Attachment: | ticket16256.patch added |
---|
comment:1 by , 13 years ago
Has patch: | set |
---|---|
Needs documentation: | set |
Owner: | changed from | to
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 13 years ago
Summary: | More class based views → More class based views: formsets derived generic views |
---|
comment:3 by , 13 years ago
Why your views are called FormSetsView, ModelFormSetsView and InlineFormSetsView, but not FormSetView, ModelFormSetView and InlineFormSetView?
comment:4 by , 13 years ago
Patch needs improvement: | set |
---|
Agreed, using "FormSet" in the name is better.
by , 13 years ago
Attachment: | ticket16256_2.patch added |
---|
FormSets to FormSet and broke edit.py into a package
comment:5 by , 13 years ago
Patch needs improvement: | unset |
---|
comment:6 by , 13 years ago
comment:7 by , 13 years ago
Just for posterity, the 's' in FormSetsView et al was due to supporting multiple formsets in the same view. I can change it back if you like.
follow-up: 9 comment:8 by , 13 years ago
With regards to handling multiple formsets in one view, I'd treat that as a separate problem. Ideally you'd want a single view that can handle forms *and* formsets. I've already attempted this (you can see it in the github repo mentioned in #16215, it's called MultiFormView), but I struggled with creating a decent API that made it easy to instantiate forms and formsets that have custom init arguments and so on.
comment:9 by , 13 years ago
Replying to AndrewIngram:
With regards to handling multiple formsets in one view, I'd treat that as a separate problem. Ideally you'd want a single view that can handle forms *and* formsets. I've already attempted this (you can see it in the github repo mentioned in #16215, it's called MultiFormView)
Yeah.. my main goal was to replicate the admin's inlines. We could create another ticket for the 'MutiFormView'...
but I struggled with creating a decent API that made it easy to instantiate forms and formsets that have custom init arguments and so on.
What do you think about what I came up with?
comment:10 by , 13 years ago
I've just made InlineAdmin a subclass of EnhancedInlineFormSet and all tests pass! Maybe the first approach on refactoring the admin with generic cbv?
One naming discrepancy I found was that I use formset_class
and form_class
and the admin uses formset
and form
. I fixed this by overriding get_formset_class and get_form_class.
by , 13 years ago
comment:11 by , 13 years ago
I think you may have introduced too much in one go, I think this can all be broken down into discrete things that need to be built. The way I see it is like this (I haven't achieved all of this with my own implementation yet):
- FormSetView and ModelFormSet view should mimic FormView and ModelFormView as closely as possible. In the same way that ModelFormMixin extends FormMixin and SingleObjectMixin, ModelFormSetView should extend FormSetMixin and MultipleObjectMixin, this way we get stuff like pagination for free (I haven't done this yet, but it was part of the plan).
- For InlineFormSetView, I think we need to respect the API for inline_formsets, ie it just simplifies building these formsets. Your implementation of this view includes the form for the owner model, which I think is too much functionality, it's part of the bigger problem of finding a mechanism to combine various forms and formsets into a single view.
- Once we have established the functionality for creating views with single formsets, we can start looking at ways to bridge the gap between (for example) the needs of the admin and the basic formset views.
I must confess that I've not got my head around all of what you've done. What is the purpose of the EnhancedFormset objects you've introduced?
comment:12 by , 13 years ago
Hi Andrew, my EnhancedFormSet et al resembles the admin's InlineAdmin, where we can set some things needed to instantiate the formset. For example, you've put extra
and can_order
inside the Mixin class, but we need to have a different set of parameters for each formset, so I made another class encapsulating this parameters.
I don't like the naming though.
About splitting everything in steps... I'm not sure about it. An implementation of inlineformsets that doesn't allow more than one inline doesn't make much sense IMO. I might bring this up in django-developers, gonna try #django-dev first.
But surely, another ticket for multiple Forms or ModelForms would be great! I think they will be fairly easy to build from what we have so far.
comment:13 by , 13 years ago
I had a go at my own implementation of what you've done with regards to editing inline formsets alongside a model (but I didn't touch the admin itself), the logic is nearly identical to your solution (largely coincidence, but I did borrow ideas for naming conventions), but I've done my best to mimic the structure of Django's existing class-based views for editing objects. The two new concrete views are:
- CreateWithInlinesView
- UpdateWithInlinesView
Each can take an inlines attribute which is a list of classes that extend InlineFormSet (which itself is just a bit of trickery around my InlineFormSetMixin which is used for the much simpler InlineFormSetView).
Code is here: https://github.com/AndrewIngram/django-extra-views/blob/master/extra_views/advanced.py
comment:14 by , 13 years ago
I do think the splitting of the view into a Create and a Update views is more like the other generic cbv views, although I end up joining them most of the times, but that's another issue.
I still need a little more time to think about making views for 1 inline and for N inlines different. That way you end up having a formset_valid() in InlineFormSet which doesn't get used and might confuse people, for example.
Anyone care to weight in on this?
Being the logic the same in both implementations we might argue that the probability of it being correct is somewhat high =)
comment:15 by , 13 years ago
I agree with AndrewIngram's plan for staying close to the already existing form related mixins and I believe rasca's approach is basically trying to do the impossible (porting admin) to early in the API design.
So let's step back a bit and first implement the formset related views and then see what glue code or concept is needed to help concrete implementations like the admin to use the new API. We shouldn't carry around potentially bad API decisions in the admin into the generic views just to get it done quicker.
comment:16 by , 13 years ago
See ticket 16418. The addition of a generic view for another object type should just be done by Subclassing the generic view and then redefining get_object() to return the new object. The ticket 16418 points out a small bug in the approach, but a simple workaround is available until it gets fixed.
comment:18 by , 13 years ago
heya,
Curious - is there any word on this ticket?
I'm guessing it's not going to hit 1.4, but any word when it might hit trunk? Would love to try this out for a project I'm working on =).
Cheers,
Victor
comment:19 by , 13 years ago
If one (or more) of the core devs could give me some direction, I'd be happy to create an updated patch based on rasca's patch. The comments above leave more ambiguity than I feel comfortable dealing with on my own.
This feature alone, for those developing their own custom admin interfaces, could be the most excellent advancement in Django since newforms (IMHO).
Thanks
Michael
comment:20 by , 13 years ago
Cc: | added |
---|
comment:21 by , 13 years ago
Cc: | added |
---|
comment:22 by , 13 years ago
Cc: | added |
---|
comment:23 by , 13 years ago
Cc: | added |
---|
comment:24 by , 13 years ago
Cc: | added |
---|
Can one of the core dev please reply to the originator. It appears he's asking the right questions - this has been sitting idle for over 4 months. I've added a separate ticket to update the docs as well. Andrew perhaps you could provide the docs patch as well?? Just a thought! In any event I'm pulling your code :)
comment:25 by , 13 years ago
Cc: | added |
---|
comment:26 by , 13 years ago
Cc: | added |
---|
comment:27 by , 12 years ago
Cc: | added |
---|
comment:28 by , 12 years ago
Cc: | added |
---|---|
Version: | 1.3 → master |
comment:29 by , 11 years ago
Cc: | added |
---|
comment:30 by , 11 years ago
Cc: | added |
---|
comment:31 by , 11 years ago
Cc: | added |
---|
comment:33 by , 10 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
There's really no reason we shouldn't be pushing for additional class based generic views to be implemented as third party packages.
See 'Django Extra Views' or 'Django Vanilla Views' as examples of these.
comment:34 by , 10 years ago
Resolution: | wontfix |
---|---|
Status: | closed → new |
comment:35 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:36 by , 10 years ago
considering this ticket as a part of gsoc proposal. so reopening. django-extra-views and django-vanila-views are great and their philosophy should be implemented in django contrib apps/ django proper.
comment:37 by , 10 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
You may reopen a ticket after there is consensus to do so on the DevelopersMailingList. Thanks.
Accepting based on a talk with Russell in #django-dev
Just attached a patch with code from django-enhanced-cbv.
You can also follow my django branch on github.
It doesn't have any docs yet.