Class based generic views

17 views
Skip to first unread message

Joseph Kocherhans

unread,
Mar 7, 2008, 2:17:40 PM3/7/08
to django-d...@googlegroups.com
I just uploaded a patch [1] for class based generic views that use
ModelForm internally. Personally, I think this makes the generic views
a lot more flexible, and gives us a great argument against
adding-yet-another-config-argument-to-generic-views (even though I
haven't heard that particular demand come up for awhile.) Just
subclass the generic view, and do what you need.

Anyhow, here's what I have in mind for the backwards compatibility story:

This patch leaves the old generic views as-is, using manipulators.
This partially fixes the problem, we get ModelForm based generic views
living side by side with the old manipulator based ones. People can
svn up without breaking anything, and convert their code at their
convenience. At some point I think we'll want to either get rid of the
old functions, or convert them to use the new classes (should be
trivial). Personally, I'd rather do the former, but I'm probably in
the minority there.

Malcolm has pointed out that the post_save method is probably not such
a great name. I agree. So, what color would *you* paint that
particular bikeshed?

Joseph

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

flo...@gmail.com

unread,
Mar 7, 2008, 4:18:05 PM3/7/08
to Django developers
+1

And I think that an equally important point here is not necessarily
that people can subclass an existing generic view, but that they can
subclass BaseView for an easier way to create their own generic
views. Anything which makes good practices for reusable apps easier
is a win in my book.

About the bikeshed, I might paint it "finish", although I think that
post_save isn't such a bad name either.

-Eric

Malcolm Tredinnick

unread,
Mar 7, 2008, 4:41:05 PM3/7/08
to django-d...@googlegroups.com

On Fri, 2008-03-07 at 13:18 -0800, flo...@gmail.com wrote:
> +1
>
> And I think that an equally important point here is not necessarily
> that people can subclass an existing generic view, but that they can
> subclass BaseView for an easier way to create their own generic
> views. Anything which makes good practices for reusable apps easier
> is a win in my book.
>
> About the bikeshed, I might paint it "finish", although I think that
> post_save isn't such a bad name either.

So that we're clear: my problem with post_save is that it isn't at all
self-explanatory. It tells you when the function runs, not what it does.
It's good friends with functions called sometimes(), on_every_request()
and only_when_necessary().

A function's name should give you some hints as to the utility of the
function. So something like construct_response(), since it's actually a
hook for providing tweaking after the main action has run when you want
to control the response -- the one thing that's hard with generic views
at the moment.

Regards,
Malcolm

--
I've got a mind like a... a... what's that thing called?
http://www.pointy-stick.com/blog/

Gary Wilson Jr.

unread,
Mar 8, 2008, 3:57:18 PM3/8/08
to django-d...@googlegroups.com
Joseph Kocherhans wrote:
> I just uploaded a patch [1] for class based generic views that use
> ModelForm internally. Personally, I think this makes the generic views
> a lot more flexible, and gives us a great argument against
> adding-yet-another-config-argument-to-generic-views (even though I
> haven't heard that particular demand come up for awhile.) Just
> subclass the generic view, and do what you need.

I like the flexibility that the class-based approach brings. I think a
similar idea could be used to clean up the duplication happening in the date
based generic views. Anyone know if that has been attempted?

> Anyhow, here's what I have in mind for the backwards compatibility story:
>
> This patch leaves the old generic views as-is, using manipulators.
> This partially fixes the problem, we get ModelForm based generic views
> living side by side with the old manipulator based ones. People can
> svn up without breaking anything, and convert their code at their
> convenience. At some point I think we'll want to either get rid of the
> old functions, or convert them to use the new classes (should be
> trivial). Personally, I'd rather do the former, but I'm probably in
> the minority there.

I'm with you on keeping them side-by-side and then removing the
manipulator-based views when we take out oldforms.

Gary

Joseph Kocherhans

unread,
Mar 8, 2008, 4:06:44 PM3/8/08
to django-d...@googlegroups.com
On Sat, Mar 8, 2008 at 2:57 PM, Gary Wilson Jr. <gary....@gmail.com> wrote:
>
> Joseph Kocherhans wrote:
> > I just uploaded a patch [1] for class based generic views that use
> > ModelForm internally. Personally, I think this makes the generic views
> > a lot more flexible, and gives us a great argument against
> > adding-yet-another-config-argument-to-generic-views (even though I
> > haven't heard that particular demand come up for awhile.) Just
> > subclass the generic view, and do what you need.
>
> I like the flexibility that the class-based approach brings. I think a
> similar idea could be used to clean up the duplication happening in the date
> based generic views. Anyone know if that has been attempted?

Not to my knowledge, but if someone else doesn't try it first, I'm
going to eventually. ;-) That goes for the list_detail ones as well.

Joseph

Reply all
Reply to author
Forward
0 new messages