On Mon, Oct 10, 2011 at 12:20 PM, tWoolie <thomas.woolf...@student.adelaide.edu.au> wrote: > I'd like to propose a project to split out the table/list > functionality and the filtering functionality in the django admin into > a seperate contrib app. This is really core functionality which is > lacking from django (in terms of being locked to the admin app). > I believe this would be beneficial because currently there are a lot > of people who love using the admin interface but find building the > same functionality into their own applications daunting at best. This > leads a lot of people to try to abuse the admin app by allowing > regular users into there. > > I propose moving a lot of the django-tables2 functionality into a > contrib app and augumenting it with filterspec. Then the admin can use > this app, or any custom subclass of Table/Filter. Currently, django- > tables2 is fantastic but has no support for filterspecs which would be > super super helpful, and would benefit from the level of [url] > abstraction that d-t2 provides. > > I'm posting to this group to gather feedback and ask if anyone would > actually like to see this happen. I believe it's something i'd love to > contribute but only if the django devs would be interested in > incorporating it.
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 %-) -- 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.
