Broadly speaking, I agree with the motivation; I'm not 100% sure I
agree about the implementation plan.
Getting "admin-like" functionality into the mainstream was one of the
prime motivations behind the introduction of class-based generic
views. Django's admin contains a number of neat features (like
fieldsets, views with inline formsets, filtering and searching) that
can be very easily implemented as a set of class-based mixins or
extensions. I've got code in private repositories that implement some
of these features; I'd like to find the time to clean them up as
generic utilities.
To my mind, the end goal should be to replace most of the internals of
Django's admin with relatively light customizations of generic
form/list functionality. Admin's filters should be a specialization of
a generic capability, not something specific to the admin.
I haven't seen django-tables2 before, so I can't comment on whether
the implementation is suitable for core as-is. However, my immediate
reaction is that if we add this, it won't be as a contrib app. This is
a piece of core functionality of generic views, not an "optional
library implementing a defacto implementation of a common pattern"
(this is the yardstick against we measure contrib proposals).
I'd also say that django-tables2, by itself, appears to be only one
small part of a much larger solution. I am aware of several efforts to
build 'admin-like' view and form functionality on top of the CBV
framework introduced in 1.3. I'd like to see a lot more consolidation
in these projects before anything is proposed for trunk.
The approach taken by django-messages should be the model here. When a
new messages framework was proposed for Django in 1.2, an effort was
made to find out all the features that were desirable, and then pull
together all those features into a third party library that borrowed
code from all the available implementations. The same approach should
be taken here -- find out all the features that we want to have in
generic views (e.g., formsets, fieldsets, filtering, ordering, table
rendering), build an amalgam library that takes the best parts from
all the available 3rd party libraries, and develop that into a single
patch that can be applied to trunk.
Yours,
Russ Magee %-)
The approach taken by django-messages should be the model here. When a
new messages framework was proposed for Django in 1.2, an effort was
made to find out all the features that were desirable, and then pull
together all those features into a third party library that borrowed
code from all the available implementations. The same approach should
be taken here -- find out all the features that we want to have in
generic views (e.g., formsets, fieldsets, filtering, ordering, table
rendering), build an amalgam library that takes the best parts from
all the available 3rd party libraries, and develop that into a single
patch that can be applied to trunk.
Hi Russell,
On 10/10/2011 06:13 AM, Russell Keith-Magee wrote:
> Getting "admin-like" functionality into the mainstream was one of the
> prime motivations behind the introduction of class-based generic
> views. Django's admin contains a number of neat features (like
> fieldsets, views with inline formsets, filtering and searching) that
> can be very easily implemented as a set of class-based mixins or
> extensions. I've got code in private repositories that implement some
> of these features; I'd like to find the time to clean them up as
> generic utilities.
FWIW, TemplateResponse was introduced in the same release as the CBVs,
and it allows these same generic utilities (sorting, filtering,
pagination) to be easily implemented as reusable decorators on top of
TemplateResponse-using views. Having tried both approaches in different
projects, I find the code using TemplateResponse and decorators more
concise, readable and maintainable than the equivalent using CBV mixins;
there are not nearly as many subtle ordering and what-calls-what-when
issues, method names to memorize, and extraneous super() noise.
If you do get the CBV versions cleaned-up and public, I'd be happy to
put together the equivalent in decorator style for a head-to-head
comparison :-)
I also agree with tWoolie that as much of the functionality as possible
should be implemented separate from anything that's tied to views, so
it's more easily reusable for e.g. filtering two different lists in the
same view. The decorators and/or mixins should be a relatively light
glue layer between views and some kind of Sort/Filter objects (roughly
analogous to the Paginator object).
Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6TGP0ACgkQ8W4rlRKtE2coFACffzpv6SZ621Qe0TARJlNYP0bX
AdEAniAeOrZNHjxTtpxz04avwZ1vA/Nj
=t1A5
-----END PGP SIGNATURE-----
> FWIW, TemplateResponse was introduced in the same release as the CBVs,
> and it allows these same generic utilities (sorting, filtering,
> pagination) to be easily implemented as reusable decorators on top of
> TemplateResponse-using views. Having tried both approaches in different
> projects, I find the code using TemplateResponse and decorators more
> concise, readable and maintainable than the equivalent using CBV mixins;
> there are not nearly as many subtle ordering and what-calls-what-when
> issues, method names to memorize, and extraneous super() noise.
I haven't tried using TemplateResponse much, but I have tried CBVs, and
I've also found with relatively small projects that mixin ordering etc
can be a real pain. Example: http://goo.gl/pzEVF
(I learnt about the type.mro() method, which was fun, but that kind of
thing should *not* be needed!)
Regards,
Luke
--
"My capacity for happiness you could fit into a matchbox without
taking out the matches first." (Marvin the paranoid android)
Luke Plant || http://lukeplant.me.uk/