1)You can't add text to a page. I want to add information from another model. For example a field of a foreign key model.
What I currently do is put that in the __unicode__ function, but it has no context as to what it is.
Then in the rest of my site(outside of admin) I use the values directly. print (model.name) instead of print (model)
2) You can't put display return values of model methods. You have to create property values. But property values are not query sets so you can't really use them, but don't realize that you need .filter until your site is super slow.
3) Inline form validation is magical. You can't just add validation to an inline form, you have to do this http://pastebin.com/CGjLX2vf
4) You can't search in foreign key form fields. I have a M2M foreign key field and when I select I have to hold ctrl and scroll with this tiny scroll bar the size of my mouse cursor and I have hundreds of items in the field.
Django comes all bundled together or not at all. IIRC, this was one of the reasons why bcrypt wasn't enabled for so long: the canonical Python library came bundled with C code.
I am excited for this, but I don't see it going into django.contrib.
FYI: I wouldn't be surprised if the parts of django-braces and django-extra-views we're using end up making it into django.core. As for the other dependencies (floppyforms and rest-framework), I'm sure there'll be further discussions if and when we start pushing for inclusion in django.contrib.
I think that's reasonable. Another thing to watch out for is Django's support for older versions of Python. While I personally know the pain of "hey this feature/syntax isn't supported in 2.6 yet", Django's team is pretty strict about that.
In either case, good luck. The project looks great.
I think the versions of Django or Python don't play into it, if it was to be included in contrib it would probably happen around Django 1.7+. By then Python 2.7/3.3 will likely be the minimum required versions of Python.
Django's docs already use Sphinx as an optional install.
Django-braces and Django-extra-views are excellent but modest extensions to Django's class-based views and would likely either become part of Django or be good starting points for extending Django's generic CBV IMHO.
So the only really controversial additions would be django-floppyforms and django-rest-framework.
I seem to recall that there has been talk in recent years about all or parts of contrib being de facto split-off from core (as opposed to the technically distinct but included status of being a contrib module), so that might factor into it too.
Your remember correctly. At the moment, the momentum seems to be too move things out of contrib (e.g. localflavor, comments). The possibility of doing the same with the admin has come up at a couple of DjangoCon panels with the core devs and on the django-dev mailing list regularly in the last few years.
Two quotes from core devs on the mailing list suggest to me there isn't necessarily a consensus about what to do:
Alex Gaynor: "Perhaps this is too far in the future looking. But at a certain point the admin must become a separate project.""
Russell Keith-Magee: "[The] admin is a contrib app for a reason -- it's a standalone app. It's entirely possible to recreate everything Django's admin does as a third party application. If a third party admin implementation were to appear that had a better feature set than the existing admin, and/or a better codebase to start from, and there was a reasonable migration path from old admin configurations to new admin configurations, that might be a viable way to get a new admin into Django."
In any case, I wouldn't be in such a hurry to rush this into django.contrib, even if that were possible (and it's not). I think that there's a lot to be said for decoupling the admin from Django's development cycle and keeping it under the management of it's own team. Otherwise, there's a risk of once again ending up right back where we are now.
From a development standpoint, it's good to have Django administration be a separate app, because a modular codebase is easy to develop. If you're a Django user, modular is good, because you can get performance and security benefits by turning off parts of the framework you don't use.
From a distribution or marketing standpoint, however, one of the best features for Django beginners -- and one of the project's original motivations -- is the ability to quickly get a basic CRUD app running, so basic usage and data entry can start to happen while advanced features are still under development.
If Django doesn't have the admin functionality out of the box, and instead the user has to confront a bewildering array of third-party add-ons, it makes the framework less attractive to new users.
If Django is trying to morph into a minimalist framework like Flask, where only the most basic functionality is included, it might lose too much of what makes it strong.
I don't know about that. I've customized the heck out of that thing (e.g. https://github.com/mazelife/django-scaffold) and it's quite possible, although you'll need to be pretty familiar with the source code. That said, this particular part of Django is definitely starting to show its age. Compare the look-and-feel and UI with something like ActiveAdmin (http://activeadmin.info/) for Rails and you'll see what I mean. What's more, the approach to "class-based views" feels disconnected to the way Django apps are written now.
Good call; I pretty much always use that for Django projects that need the admin these days. I haven't done an exhaustive side-by-side comparison, but my impression is still that ActiveAdmin provides a more polished user experience.
1) (minor) Getting into templates to add an action e.g. «export as CSV» is a lot to ask. (Anything that leads me into changing the templates is, at least for me, a no, except form ergonomy which is in Django regularly done in an API/DSL based on nested dict, list and attributes.)
2) (minor) Custom models (non django.models.Model) or specifiq models (like django scaffold) in the ObjectList aka. ChangeList or in the Form view is not possible which means no mongodb, no kv store, no to anything that hasn't a proper Django's model backend even if in the end it's all about class properties and most of the time slice queries.
3) (major) The admin ergonomy and plugability is poor, you can not choose the way pages feet together, for instance and the primary concern is that the first page must be a list of models regrouped by apps. This is in advanced apps a non sens, most likely when you use a lot of reusable apps, where the code doesn't reflect the end-user experience, the admin will look ugly. But should the admin reflect or map somehow the end-user experience ? It's a complex mapping, the workflow of the admin is elaborate and depends of the app... otherwise said the Django «generated» admin is the equivalent of a spreadsheet compared to specific domain admin areas.
Does it support filters and actions ? because what it looks like you did is that you are feeting a view to the admin API, leaving the elaborate actions and points of customisation on the side.
> and it's quite possible,
It our job to make things possible.
> although you'll need to be pretty familiar with the source code.
You mean read the code ? It's not that difficult. Also I think django admin reworks bring more clarity.
> That said, this particular part of Django is definitely starting to show its age.
In terms of features or skin ?
> Compare the look-and-feel and UI with something like ActiveAdmin (http://activeadmin.info/) for Rails and you'll see what I mean.
Definetly looks like a customised Django Admin. Also Django Admin already had it's skin war, the feature/API war is barely starting.
> What's more, the approach to "class-based views" feels disconnected to the way Django apps are written now.
I'm not sure I follow all the points you're making. But...
1.) I've created CSV import/export admin functions for models many times and I agree it's a minor customization. I'm not sure why changing templates is a no-go for this or anything else.
2.) To me it seems self-evident that the admin was designed to facilitate model-oriented CRUD operations. The fact that it's hard to integrate non-relational data stores like mongo have nothing to do with the admin, and everything to do with the fact that there is currently no agreed on way to plug NoSQL data stores into Django's ORM. Although this has been is a longstanding point of contention and there was a GSOC project that I think eventually became http://www.allbuttonspressed.com/projects/django-nonrel , my sense is that there just wasn't/isn't enough interest in making this a part of Django core. In other words, this goes well beyond what I would call "admin customization" and get's down to pretty basic questions about what sorts of persistent data stores should be supported by the ORM.
3.) Again, this seems to me to want to be able to stretch the admin beyond what it was designed for. To your point: "the first page must be a list of models regrouped by apps. This is in advanced apps [nonsense], most likely when you use a lot of reusable apps, where the code doesn't reflect the end-user experience, the admin will look ugly. But should the admin reflect or map somehow the end-user experience? It's a 'complex mapping'."
I agree! This is potentially a very complex mapping. While it would be wonderful if there was some way to handle these sorts of things while retaining the easy-to-use, declarative nature of the current ModelAdmin approach, that's a tall order. The right answer at that point might be: build you own admin.
With all props to the current admin, the areas where I see it "starting to show it's age" are skin, user experience, and features. I don't present Rails' ActiveAdmin as a lightyears-ahead-alternative, just an example of an admin that is incrementally better than Django's in those areas I mentioned.
When I say the admin approach to "class-based views" feels disconnected , I mean that while it is technically correct to say that, for example, https://github.com/django/django/blob/master/django/contrib/... is a "class-based" view, it's not a capital-C Class-Based View. In other words, this is an area where features that have been developed in core have not made it back into the admin, even though they could be enormously beneficial and help to make the whole thing more pluggable. That actually seems to be one of the goals of django-admin2, which is great news.
It may be that you and I don't really disagree here all that much. I was responding to the statement of the parent: "try to do anything custom [with the admin] and you're screwed," which I don't think is true. But there are definitions for "custom"--things that go way beyond providing a simple way to model-oriented CRUD operations--that present some real challenges. And frankly, they may go beyond what a general-purpose, easy-to-configure admin can or should do.
(unrelated to my point: the example app of mine I cited does not support filters and actions. It certainly could, if I or someone else had the time to and the need to add it. But it presents some thorny UX problems like "what does it mean to filter out model instances from the list view when the instances are also nodes of a tree? Where do the children go?")
I'd like to hear some specifics. Over the last six years I've surveyed and sampled a wide range of extensions, add-ons and integrations into the admin and it's proved astonishingly flexible so far.
Yes - there's things that people would probably do differently now and it's overdue for an overhaul but the degree of extensibility they managed to enable with the initial design decisions was fairly incredible.
