--
Ticket URL: <https://code.djangoproject.com/ticket/16256>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* owner: nobody => rasca
* needs_docs: => 1
* has_patch: 0 => 1
* stage: Unreviewed => Accepted
Comment:
Accepting based on a talk with Russell in #django-dev
Just attached a patch with code from [https://github.com/rasca/django-
enhanced-cbv django-enhanced-cbv].
You can also follow [https://github.com/rasca/django/tree/ticket16256
-more-class-based-views my django branch on github].
It doesn't have any docs yet.
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:1>
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:2>
Comment (by anonymous):
Why your views are called FormSetsView, ModelFormSetsView and
InlineFormSetsView, but not FormSetView, ModelFormSetView and
InlineFormSetView?
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:3>
* needs_better_patch: 0 => 1
Comment:
Agreed, using "FormSet" in the name is better.
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:4>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:5>
Comment (by rasca):
I have just closed #16215 in favor of this one. We should review the code
in #16215 to look at what he may have done better in terms of API.
The idea is to keep it as close as possible to the forms API.
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:6>
Comment (by rasca):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:7>
Comment (by 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), 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:8>
Comment (by rasca):
Replying to [comment:8 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?
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:9>
Comment (by rasca):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:10>
Comment (by AndrewIngram):
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):
1. 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).
2. 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.
3. 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?
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:11>
Comment (by rasca):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:12>
Comment (by AndrewIngram):
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
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:13>
Comment (by rasca):
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 =)
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:14>
Comment (by jezdez):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:15>
Comment (by kd4ttc):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:16>
Comment (by victorhooi):
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
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:18>
Comment (by MichaelA):
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
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:19>
* cc: anton@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:20>
* cc: GotenXiao (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:21>
* cc: aaron@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:22>
* cc: emyller@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:23>
* cc: rh0dium (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:24>
* cc: gerdemb (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:25>
* cc: treyhunner (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:26>
* cc: charette.s@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:27>
* cc: hanne.moa@… (added)
* version: 1.3 => master
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:28>
* cc: MarkusH (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:29>
* cc: dpwrussell (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:30>
* cc: ville@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:31>
Comment (by Fabio Caritas Barrionuevo da Luz <bnafta@…>):
What is the status of this?
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:32>
* status: new => closed
* resolution: => wontfix
Comment:
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.
* https://github.com/AndrewIngram/django-extra-views
* https://github.com/tomchristie/django-vanilla-views
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:33>
* status: closed => new
* resolution: wontfix =>
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:34>
* status: new => assigned
* owner: rasca => auvipy
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:35>
Comment (by auvipy):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:36>
* status: assigned => closed
* resolution: => wontfix
Comment:
You may reopen a ticket after there is consensus to do so on the
DevelopersMailingList. Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/16256#comment:37>