> 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.
I think we all have code like this sitting around. It would be great to standardise this code into a common package/platform > 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. Sorry if i wasn't clear but this is exactly what i want to do: namely take the magic out of admin, and turn the admin into a thin wrapper over standardised tables/filters > I haven't seen django-tables2 before, so I can't comment on whether > the implementation is suitable for core as-is. Think of the django forms declarative syntax, but for tables. It's really quite neat but in need of some refactoring that can't be done in dt2 as it would seriously break backwards compatibility. >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). The problem I see here is that while tables are awesome, they are in no way a view. and limiting a view to having a single table, or filterset does not sit right with me. Class based views are great, but are not a catch-all solution. > 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 inclusion of views that have tables "baked in" is a great idea, but really the wrapper would be so thin as to be trivial. The point of this effort is to consolidate declarative tables/filters, not build generic views. > 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. I'm more than happy to build this as a third party app (better_admin?), but part of the appeal for me is to rebuild admin without the magic, not introduce a competing admin that nobody knows about. As far as CBV is concerned, this is a non-starter. these features extend beyond generic views. perhaps as a convenience after the majority of the work is done. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
