Hi, On 10 October 2011 15:20, 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. > > Thomas Making the admin's codebase more flexible and reusable is definitely something that we should aim for. In fact, there have been lots of group discussions about this during DjangoCon. Idan and I will try to post a detailed summary to this list soon. In a nutshell, the aim is to make the admin more lightweight and modular so that its various components can easily be replaced or used in different contexts. It's quite likely that a full rewrite will eventually be necessary, following the same path as oldforms/newforms: "newadmin". However, I think at this stage one great way to start would be to refactor the current admin to make use of class-based views. This would be good for a number of reasons: - Dogfooding: having a concrete real-world app in Django core would help drive improvements and extensions to the CBVs themselves. - The admin codebase would reach a position where abstracting its core functionality out gets easier. - This would help quickly anticipate issues (both from a technical and usability point of view) to do with ravioli code [1]. - A complete rewrite would likely take time and would realistically not ship in Django before the next 2-3 releases -- unless someone pulls out the work to make me lie :-). Adding CBVs would quickly open the door to a lot of possible improvements in oldadmin, which would in turn inform the parallel development of newadmin. - This would make the future transition and upgrade path to newadmin easier. If someone is willing to take this on then I'd be happy to provide some support by reviewing patches, giving feedback etc. Cheers, Julien [1] http://lukeplant.me.uk/blog/posts/class-based-views-and-dry-ravioli/ -- 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.
