> 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
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
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
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
> 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
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
>
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
-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
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
>
> 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
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
>
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
+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
13 matches
Mail list logo