Héllo,
Since my initial introduction, I tempered my excitement and tried to have a better understanding of the issues faced by the admin following the Django's guide to contribute<https://docs.djangoproject.com/en/dev/internals/contributing/>, which resulted in me writing a post <http://amirouche.github.com/blog/django-admin-next.html> which I wish to contribute in a form or another in the AdminNext wiki page<https://code.djangoproject.com/wiki/AdminNext>. I also did this because I couldn't get feedback the lazy way<https://groups.google.com/forum/?fromgroups=#!topic/django-users/Mp-4zQMoQJs>, I'll bump the thread later in the month answering the questions myself and I invite you to do the same so that more people get interested in the discussion or start another topic with more relevant questions. First, there is already work done regarding a new version of the admin that can be BC: - Dogfood class-based views in contrib.admin #17208<https://code.djangoproject.com/ticket/17208> - Making it easier to customize Django Admin #18665<https://code.djangoproject.com/ticket/18665> - View collections #16213 <https://code.djangoproject.com/ticket/16213> - API for simpler (permission or any) checks for generic view classes #15215 <https://code.djangoproject.com/ticket/15215> those have all code, are abandonned or not claimed anymore, all accepted except the last which needs a design decision. In the analyze I did, I tried do separate the problem into two different topics: - *code features* are all things put in place by the admin to make it possible to build upon it and implement user features - *user features* is what is expressed as needs by the user, the general ergonomic, the things they need to be able to do For instance «an application overview» is an user feature, the related code feature that will allow to do that are «dashboard API», «template overriding» and «hook another view in the admin site». What I think is that the admin is too much focused on code features notably on models. I think the admin is model centric, to my mind it would be better if it was groups-centric, groups of users and groups of process or permissions which in Django is simply referred as group. To my mind this reflexion doesn't change the fact that the admin should be more extensible and pluggable. So what I envision right now about AdminNext is the following: - Pluggable and extensible admin components - Groups centric API to build application backends - Use the above to implement a similar admin as current admin I still think django-composite can be relevant, but I need to tweak it a bit and also fully implement the ChangeList to have more things to back it. If composite is not accepted then I think it's still possible to achieve something similar with template tags. Spoiler: django-composite is meant to be able to replace template tags in certain scenario. I think it's possible to do this BC and follow Django deprecation policy, but it won't be the quickest. I have no experience regarding this subject, but the worst scenario would be to do it outside without community feedback and then port all the things to Django which would result in the same path as the one that had followed the BC way. Amirouche -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/OZK3tKIuo-4J. 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.
