> Russell Keith-Magee <[email protected]> Jan 28 10:28AM +0800
>
>> feature is out of scope. A lot of people believe that it should be in
>> scope. Therefore I would like to politely request a reconsideration of
>> this decision.
>
> Even though I'm the person who wonfixed the ticket most recently, I'm
> inclined to agree with you -- but for a different reason.
>
> The original reason -- that the admin isn't intended as a general
> purpose site, just a backend editing interface -- is still valid. I'm
> not in favor of trying to turn the admin into something that people
> will try to interpret as a publicly visible CMS.

I agree 100%. The admin should remain the admin.

> I'd also point out that at DjangoCon.US last year, there were some
> initial discussions about developing a "NewAdmin". I don't think this
> effort has gone very far since then, but it's worth noting that there
> is high-level agreement that Django's admin is in need of a bit of a
> shakeup; increased functionality (like view permissions) might be
> something that could fit into that broader change.

Working with NoSQL these days I found the first big problem in Django
was the lack of a reliable django.contrib.admin alternative that works
with NoSQL. I looked into various third party apps that stapled
themselves into the Django Admin, and was unhappy. Why? Because the
Django Admin was designed for the ORM, and stapling additional non-ORM
functionality on it was outside it's original design scope.

I think increasing that design scope is a bad idea. The admin should
remain pretty much as it is, just incrementally changed to match the
rest of Django.

However, I think there is a viable alternative available right now.
And that is using CBVs and *perhaps* the existing css/js from the
admin to create 3rd party comparable tools that could include
non-editable views, NoSQL views and more all following a relatively
common pattern. It's not that hard, and it is certainly easier than
trying to either extend django.contrib.admin to a crazy extent or
rolling a new hyper-abstracted newadmin.

My first effort is django-mongonaut. It's still pretty new, but we are
using a more feature complete version in production now
(django-mongonaut is basically an extraction like Django was extracted
from Ellington). It has non-editable views for non-staff users and
fully editable views for people with rights.

In any case, I'm not advocating of django-mongonaut, I'm advocating
it's approach. Which is new code in 3rd party apps to solve new
problems but using the old patterns established by
django.contrib.admin. I think this is is the better, easier way to go
because it keeps Django's core scope smaller. Which makes advancement
of the framework easier for the hard-working people who contribute to
it.

-- 
'Knowledge is Power'
Daniel Greenfeld
http://pydanny.blogspot.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to