Re: Splitting out admin functionality

2011-10-10 Thread tWoolie
> Yep. Could you outline your plan of attack for this? 1) create "newadmin" project to be a dropin replacement for admin. (Clone current admin and slowly replace features/trim dead code) 2) Split out filterspec functionality into newadmin.filter. - Give it a nicer wrapper such that a

Re: Splitting out admin functionality

2011-10-10 Thread Julien Phalip
On 11 October 2011 14:04, tWoolie wrote: > > Yep. Could you outline your plan of attack for this? > > 1) create "newadmin" project to be a dropin replacement for admin. >(Clone current admin and slowly replace features/trim dead code) > > 2) Split out

Re: Splitting out admin functionality

2011-10-10 Thread Yo-Yo Ma
What would be the value in replacing the admin with a new version with abstracted, reusable tools... that still resides in the new admin? IMO, duplicating the admin's features would be better than that (assuming you can't simply change the admin's guts in-place, which is probably the case). On

Re: Splitting out admin functionality

2011-10-10 Thread Julien Phalip
On 11 October 2011 12:22, tWoolie wrote: > > If someone is willing to take this on then I'd be happy to provide some > > support by reviewing patches, giving feedback etc. > > Cheers. Would you be willing to review code that swaps out entire > swathes of

Re: Splitting out admin functionality

2011-10-10 Thread tWoolie
> If someone is willing to take this on then I'd be happy to provide some > support by reviewing patches, giving feedback etc. Cheers. Would you be willing to review code that swaps out entire swathes of admin functionality? -- You received this message because you are subscribed to the Google

Re: Splitting out admin functionality

2011-10-10 Thread Julien Phalip
Hi, On 10 October 2011 15:20, tWoolie 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 >

Re: Splitting out admin functionality

2011-10-10 Thread Luke Plant
On 10/10/11 17:10, Carl Meyer wrote: > 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

Re: Splitting out admin functionality

2011-10-10 Thread Carl Meyer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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

Re: Splitting out admin functionality

2011-10-10 Thread Andrew Ingram
On 10 October 2011 13:13, Russell Keith-Magee wrote: > > 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 >

Re: Splitting out admin functionality

2011-10-10 Thread tWoolie
> 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

Re: Splitting out admin functionality

2011-10-10 Thread Russell Keith-Magee
On Mon, Oct 10, 2011 at 12:20 PM, tWoolie 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 >

Re: Splitting out admin functionality

2011-10-10 Thread Yo-Yo Ma
To further note; while I second the OP's request, in its abstract, my approach wouldn't be to add another contrib app. It would be to implement a fairly low level API. Reuse of a third party app, or abstracting some of the existing admin code, or any combination thereof would be sufficient, but

Re: Splitting out admin functionality

2011-10-10 Thread Yo-Yo Ma
+1 I spent this Saturday morning implementing ad hoc table sorting in a ListView's get_queryset. It felt very wrong, to say the least. An abstracted sorting and filtering framework, along with a few of the admin-ish features that are already in core (inline model formsets, et al) provide some