RFC: More class based views, take two

[Iván Raskovsky]

The generic class based views were introduced in 1.3, since then they
haven't seen much love. I feel the most wanted missing views are the
formsets related ones (specially the inline_formsets related ones).

I've written to the list some months ago[0] with no reply. Luckily I'll
get more traction this time. Several projects have popped up[1, 2, 3] to
cover this area. Each one has different approaches.

Ticket #16256[4] is tracking this changes

* enhanced_cbv[0] *

Tries to maintain a similar API to the existing views and the admin
inlines. Creates three generic views for a multiple formsets view, multiple
model_formsets view and a model with multiple inline_formset view. Joins
the update and create views in one view.

* extra-views[1] *

Keeps the current API as much as possible adding views for a one formset
and for one model_formset and adds views for working with
inline_formsets and generic inline_formsets.

* cbv_utils[2] *

I haven't played much with this one yet, but it only adds a view to work
with inline_formsets. It also proposes changes to the existing CVB APIs
to simplify adding this views[5].

Another related ticket is #10403[6]: a declarative syntax to define
FormSets so we don't need a special wrapper around the factories
simplifying creating inlines in a similar fashion as the admin's
InlineModelAdmin.

So, we have 3 tested and working alternatives for these views. I think
none of them is polished enough as for inclusion to core.

I have no idea how to move forward. Right now it seems kinda stalled.
Should we pick one implementation and start moving forward with that
one? If so, which one? Should we start a wiki page discussing the
different API decisions we need to make?

I think we have the manpower to make this possible, the three
implementations shows people really need this in their projects and I'm
more than willing to spend time working on this.

Any feedback will be greatly appreciated,
Iván

[0] https://groups.google.com/d/msg/django-developers/aWRDIwDKDG8/gW3RGurxoZoJ
[1] https://github.com/rasca/django-enhanced-cbv
[2] https://github.com/AndrewIngram/django-extra-views/
[3] https://github.com/tswicegood/cbv_utils
[4] https://code.djangoproject.com/ticket/16256
[5] https://code.djangoproject.com/ticket/17557
[6] https://code.djangoproject.com/ticket/10403

[Andrew Ingram]

Hi Iván,

I'd temporarily given up on getting extra_views into Django because of
a blocking issue with pagination and formsets.

Assuming a goal is to be able to build a new admin using class-based
views, there is a prerequisite of being able to paginate, sort and
filter on the querysets used for modelformsets. The problem is that
with Django's class-based views as they are, pagination is handled at
the template context stage of the logic, whereas the formsets are
instantiated and validated much earlier. I had raised a ticket about
fixing this, but it was closed as wontfix because it would almost
certainly introduce backwards-incompatible changes

On a related now, you mentioned that none of the libraries you've
mentioned are sufficiently polished. What further work do they need?
As I see it, my main omission right now is documentation, though that
is in progress.

Regards,
Andy

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

[Iván Raskovsky]

Hi Andy,

On Mon, May 28, 2012 at 7:30 AM, Andrew Ingram <an...@andrewingram.net> wrote:
> Hi Iván,
>
> I'd temporarily given up on getting extra_views into Django because of
> a blocking issue with pagination and formsets.
>
> Assuming a goal is to be able to build a new admin using class-based
> views, there is a prerequisite of being able to paginate, sort and
> filter on the querysets used for modelformsets. The problem is that
> with Django's class-based views as they are, pagination is handled at
> the template context stage of the logic, whereas the formsets are
> instantiated and validated much earlier. I had raised a ticket about
> fixing this, but it was closed as wontfix because it would almost
> certainly introduce backwards-incompatible changes

I'm not sure how to work around the issue, I didn't spend much time on
it. But for sure we can either find a BC way to solve this or revisit
that wontfix.

> On a related now, you mentioned that none of the libraries you've
> mentioned are sufficiently polished. What further work do they need?
> As I see it, my main omission right now is documentation, though that
> is in progress.

I agree your implementation is very well done (nicer than mine), but
from a quick inspection I could find:

* There are almost no docstrings
* One can abstract part of the code in BaseFormSetMixin and FormMixin
into a new Mixin
* get_initial() could get a .copy() as in
https://github.com/django/django/blob/master/django/views/generic/edit.py#L18
* I don't agree with the get_success_url implementation (it defers
from the current ones)
* There's a get_context_data() in FormSetMixin that I think shouldn't live there
* I think you are not taking into consideration formsets prefixes clashing
* I'm not sold on BaseInlineFormSetMixin inheriting from
BaseFormSetMixin: do you really need e.g. get_context_data in there if
you won't use it?

This is just a quick list I made while skimming through the code and
what I remember from past months. I'm more than glad to be proven
wrong! I'm sure you can make a similar list quickly with my
implementation, I think the best thing we can do is work together,
this is a big ticket. Get the best of each implementation and merge it
together. It's time to get the ball rolling.

Regards,
Iván

[Julien Phalip]

Hi Andy and Iván,

Backwards-compatibility should be a primary goal, however it is also ok to consider breaking that compatibility if it becomes necessary in order to have a clean and more easily maintainable codebase, as long as the upgrade path remains simple.

This is a significant piece of refactoring and it's hard to predict the full extent of the impact it will have on legacy projects and third-party apps. If you guys are keen to continue working on this then I encourage you to pursue. I'm also glad to help where I can. For a start, I've made a first pass at rewriting the admin views into CBVs in ticket #17208 (https://code.djangoproject.com/ticket/17208).

Once good progress has been made, then it would also be very helpful to keep the maintainers of all major custom admin apps (Armstrong, FeinCMS, Django-CMS, Grapelli, Mezzanine, etc.) in the loop for feedback.

Thanks a lot for your great work!

Julien