Re: Django Admin New Look

[Andy Baker]

Hi,

Is this thread still the most up to date place for discussing this? I'm 
trying to work out what the current status is and whether it is likely to 
land in 1.9.

For the benefit of anyone else coming to this late here's what I can track 
down:

Last comment here prior to mine was jezdez on April 14th

The standalone repo is here: https://github.com/elky/django-flat-theme 
(last commit May 8th)

The Trac ticket is here: https://code.djangoproject.com/ticket/2#ticket 
(Status: 'accepted' but 'patch needs improvement' - last change May 11th)

The original pull request is 
here: https://github.com/django/django/pull/4232 (Status closed. last 
update: March 11th)

So it looks like it's still on track - I just can't find any recent 
discussion on it. If that's normal then apologies for the noise.

On Wednesday, 4 March 2015 19:15:33 UTC, elky wrote:
>
> Hi guys,
>
> I think django admin needs new look. I played with styles recently and 
> that's the result: https://github.com/django/django/pull/4232
>
> Inspired by a new djangoproject.com site. 
>
> New theme looks modern, fresh and clean. There are CSS changes only. No 
> any HTML changes.
>
> Let's discuss it. I will appreciate any feedback.
>
> Thanks
>
> P.S. I can create demo app if it needs.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7e1aa24b-80a9-4ca4-ab69-ab128d90d679%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

A modest proposal - more blocks in admin templates

[Andy Baker]

Happy to do some work on this but wanted to get some feedback first.

Loose methodology:

1. Skim the most popular admin extensions that exist on django-packages etc
2. Look out for places where they've had to copy entire admin templates to 
only override a small part
3. Add new {% blocks%}  into the original templates where there appears to 
be a demonstrable need.

Additionally - would there be some value in a new page in the docs listing 
admin templates and their respective blocks?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/52b62608-6bf1-4f64-8e2f-5fffc5669366%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A modest proposal - more blocks in admin templates

[Andy Baker]

In terms of increasing the likelihood of a patch that will get merged:

1. Is it better to leave the documentation issue to one side for now?
2. Would it be better to tackle a subset of the admin templates first or is 
it better to try and swallow this whole?
3. Would a core committer need to adopt this to make sure it doesn't 
languish?

On Friday, 24 July 2015 14:51:44 UTC+1, Tim Graham wrote:
>
> As in something like, "We won't make changes to template blocks without a 
> mention in the release notes."? If we need to make a change for a good 
> reason, I am not sure what a deprecation would look like, if at all 
> possible.
>
> On Friday, July 24, 2015 at 9:37:18 AM UTC-4, Collin Anderson wrote:
>>
>> The documentation could give better backwards compatibility guarantees. 
>>
>> On Friday, July 24, 2015, Tim Graham  wrote:
>>
>>> There is at least one ticket about adding more blocks to the admin 
>>> templates: https://code.djangoproject.com/ticket/14810
>>>
>>> You can browse the "contrib.admin" component in Trac to find related 
>>> issues: 
>>> https://code.djangoproject.com/query?status=assigned&status=new&component=contrib.admin&stage=Accepted&page=2&col=id&col=summary&col=status&col=owner&col=type&col=version&desc=1&order=id
>>>
>>> I am not sure how much value documentation would be as it seems if you 
>>> are overriding the template, you will probably need to look at the whole 
>>> thing anyway.
>>>
>>> On Friday, July 24, 2015 at 5:35:28 AM UTC-4, Andy Baker wrote:
>>>>
>>>> Happy to do some work on this but wanted to get some feedback first.
>>>>
>>>> Loose methodology:
>>>>
>>>> 1. Skim the most popular admin extensions that exist on django-packages 
>>>> etc
>>>> 2. Look out for places where they've had to copy entire admin templates 
>>>> to only override a small part
>>>> 3. Add new {% blocks%}  into the original templates where there appears 
>>>> to be a demonstrable need.
>>>>
>>>> Additionally - would there be some value in a new page in the docs 
>>>> listing admin templates and their respective blocks?
>>>>
>>>  -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/2ecc568c-0aa9-4a67-af31-f8c877699c92%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/2ecc568c-0aa9-4a67-af31-f8c877699c92%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0e83b74a-0253-4679-9cad-04f3c7a054a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A modest proposal - more blocks in admin templates

[Andy Baker]

Great. I'll do that. Cheers for the advice.

On Friday, 24 July 2015 15:55:24 UTC+1, Tim Graham wrote:
>
> I'd start small, for example, by fixing the existing ticket I pointed out 
> and any others that are related. Create a new ticket for any other changes.
>
> I think there might be a tiny performance penalty to parsing blocks 
> (someone else can probably speak better to this). Also, too many blocks 
> might cause difficulties with backwards compatibility if we need to 
> restructure things in the future. Those are the only controversial points I 
> can think of. Send a pull request after changing a few templates so we can 
> get a flavor and see if you are on the right track.
>
> We don't have a big problem with trivial patches like this languishing.
>
> On Friday, July 24, 2015 at 10:43:38 AM UTC-4, Andy Baker wrote:
>>
>> In terms of increasing the likelihood of a patch that will get merged:
>>
>> 1. Is it better to leave the documentation issue to one side for now?
>> 2. Would it be better to tackle a subset of the admin templates first or 
>> is it better to try and swallow this whole?
>> 3. Would a core committer need to adopt this to make sure it doesn't 
>> languish?
>>
>> On Friday, 24 July 2015 14:51:44 UTC+1, Tim Graham wrote:
>>>
>>> As in something like, "We won't make changes to template blocks without 
>>> a mention in the release notes."? If we need to make a change for a good 
>>> reason, I am not sure what a deprecation would look like, if at all 
>>> possible.
>>>
>>> On Friday, July 24, 2015 at 9:37:18 AM UTC-4, Collin Anderson wrote:
>>>>
>>>> The documentation could give better backwards compatibility guarantees. 
>>>>
>>>> On Friday, July 24, 2015, Tim Graham  wrote:
>>>>
>>>>> There is at least one ticket about adding more blocks to the admin 
>>>>> templates: https://code.djangoproject.com/ticket/14810
>>>>>
>>>>> You can browse the "contrib.admin" component in Trac to find related 
>>>>> issues: 
>>>>> https://code.djangoproject.com/query?status=assigned&status=new&component=contrib.admin&stage=Accepted&page=2&col=id&col=summary&col=status&col=owner&col=type&col=version&desc=1&order=id
>>>>>
>>>>> I am not sure how much value documentation would be as it seems if you 
>>>>> are overriding the template, you will probably need to look at the whole 
>>>>> thing anyway.
>>>>>
>>>>> On Friday, July 24, 2015 at 5:35:28 AM UTC-4, Andy Baker wrote:
>>>>>>
>>>>>> Happy to do some work on this but wanted to get some feedback first.
>>>>>>
>>>>>> Loose methodology:
>>>>>>
>>>>>> 1. Skim the most popular admin extensions that exist on 
>>>>>> django-packages etc
>>>>>> 2. Look out for places where they've had to copy entire admin 
>>>>>> templates to only override a small part
>>>>>> 3. Add new {% blocks%}  into the original templates where there 
>>>>>> appears to be a demonstrable need.
>>>>>>
>>>>>> Additionally - would there be some value in a new page in the docs 
>>>>>> listing admin templates and their respective blocks?
>>>>>>
>>>>>  -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "Django developers (Contributions to Django itself)" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to django-developers+unsubscr...@googlegroups.com.
>>>>> To post to this group, send email to 
>>>>> django-developers@googlegroups.com.
>>>>> Visit this group at http://groups.google.com/group/django-developers.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/django-developers/2ecc568c-0aa9-4a67-af31-f8c877699c92%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/django-developers/2ecc568c-0aa9-4a67-af31-f8c877699c92%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/33be9cfe-127c-4bb3-82f0-fc0506695183%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Andy Baker]

I do a lot of projects with highly customized admins and having the full 
font awesome would be splendid.

One option is to use optional requirements: pip install django[all-icons]
but I don't think Django does this anywhere else so it's probably a big 
leap for a small part of contrib.admin

Maybe all that's is needed is a simple wrapper app that packages the full 
font-awesome on the correct static path and it's as simple as documenting 
it thus:

"If you want all the font awesome icons to be available put this app in 
INSTALLED_APPS after contrib.admin and it will overwrite the minimal icon 
pack with the full one"

On Wednesday, 29 July 2015 12:13:15 UTC+1, elky wrote:
>
> Hi guys,
>
> I'm glad to say I finished work on replacing image icons with font. I used 
> Font 
> Awesome  (GPL licence) kit to 
> do it.
>
> I'll appreciate if you test new icons in your project and report any 
> issues here . You can 
> do it by running:
> pip install git+https://github.com/elky/django-flat-theme.git@flat-icons 
> --upgrade
>
> There are couple of questions I wanna discuss in this thread:
>
> 1. Font Awesome kit contains about 600 icons - obviously we don't need all 
> of them in Django. I can create small kit which will contain only icons 
> that used in the project - it will allow us to save about 70KB. But the 
> question is - how to support this kit in future if someone decide to add 
> new icons?
>
> 2. Do we support IE8 and less? If yes - I'll need to add additional font 
> files.
>
> Thank you,
> Alex D.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ee879f3f-e57c-49f1-9597-2979942fc02f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Field.get_flatchoices seems to never get used

[Andy Baker]

I'll file a ticket but I wanted a quick sanity check first.

In db.models.fields.Field there is a method called get_flatchoices (as well 
as _get_flatchoices which is turned into a property).

I've searched the source for 'get_flatchoices' and it's never called. There 
doesn't appear to be any mention of it except in a few ancient tickets.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6ba31eda-8f84-490a-8dce-0448452c9510%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Try out new inline features [GSoC admin-ui]

[Andy Baker]

Mmmm. That's a fair point but that article was written before web
applications were so application-ey and expectations may well have
changed. (I've noticed a lot of semi-modal dialogs in web apps
complete with 'cancel' buttons and with javascript dialogs the back
button doesn't do what Jakob implies people expect)

So there is a lot of subtlety here and I'd like to get more data. It
never occurred to me that Cancel was needed until I watched a user
flounder when they didn't know how to get out of the change screen.

> Usability experts disagree with you vehemently:
>
> http://www.useit.com/alertbox/2416.html
>
> Cheers
>
> Tom
>
>
> >
>

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

Re: The low down on the "Unsettings" project

[Andy Baker]

This sounds really interesting. Is there anything about this in writing? 
I'm not a fan of listening to audio on tech subjects (must... skim... 
read...). Not sure if anyone else shares this prejudice but do post here if 
there is a follow-up blog post or similar.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8997f769-6905-4e11-8a40-80b6a23d63ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

The 'rule'

[Andy Baker]

Hi,

I was about to start a discussion about a patch I'd like to contribute when 
I remembered there is a rule about contributions.

Is it the '5 for 1' rule? Something like that - the regulars here will know 
immediately what it is I'm trying to remember!

I did try and find it 
here: https://docs.djangoproject.com/en/1.7/internals/contributing/ but 
couldn't spot it. It's hard to search for something when you can't remember 
what it's called...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/30a19b80-7d77-4702-9a43-ff25b609553c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal new Django Admin css style

[Andy Baker]

I really like Thiago's new skin and I love the fact it's CSS only.

The key thing to remember in any discussion about updating the admin is 
that there are three levels:

1. CSS/Static only - little to no breakage of 3rd party apps 
2. Updated HTML - many apps that overrride admin templates or rely on 
specific markup will break   
3. Probably complete breakage of all 3rd party admin apps - it had better 
be worth it!

So far I'm sticking with #1...

I feel #2 gives you most the breakage and not enough of the benefits. If 
we're going to break things, then we might as well go the whole hog. And to 
be that probably looks like a big decoupling and modularisation rather than 
just a new admin per se. Hopefully something close to what Tom Christie is 
proposing in his Django Rest Framework Kickstarter. Something that would be 
usable outside strictly 'admin' scenarios but still give you the 
push-button CRUD we all love. 


On Friday, 1 August 2014 14:47:25 UTC+1, Thiago Avelino wrote:
>
> Hi guys! Django admin has a few years, it works fine (meets the need) only 
> need to evolve the style following the evolution of UX today!
>
> We have a plan for change?
>
> What do you think of this style ​
> https://github.com/hersonls/djamin#screenshots ? Is django admin html + 
> custom css!
>
>
> Cheers,
> Thiago Avelino
> @avelino0  - avelino.xxx
>

On Tuesday, 19 August 2014 11:39:20 UTC+1, Areski Belaid wrote:
>
> There is a full list of django-admin alternatives here:
> https://github.com/rosarior/awesome-django#admin-interface
>
> Personally, I have a very good experience with xadmin which have only one 
> dependency (django-crispy-forms)
>
>
> On Monday, August 18, 2014 6:20:36 AM UTC+2, Daniel Greenfeld wrote:
>>
>> Thanks for the mention, but I haven't had time to work or maintain that 
>> for months. I'm not sure how it works with the upcoming Django 1.7.  Also, 
>> for the sake of simplicity, the default skin for it is bootstrap 3. Any CSS 
>> in there is per skin, and probably doesn't belong in this discussion.
>>
>> On Sunday, August 17, 2014 11:18:33 AM UTC-3, Danilo Bargen wrote:
>>>
>>> Just for the record, there's also 
>>> https://github.com/pydanny/django-admin2, another project that attempts 
>>> to create a more modular and extensible admin. 
>>>
>>> Danilo 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0d61cbdb-ab61-4435-bdc0-7bde2595a6ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

[Andy Baker]

I can't help but feel that the "admin is very rudimentary and hard to 
customize" is perpetually overplayed by many in the community. Maybe I'm 
suffering Stockholm Syndrome but I'd like to raise a dissenting voice.

I find it the quickest and most efficient way to provide an admin interface 
for staff users. It's remarkably easy to customize in my view (and I've 
done a heck of a lot of it). If it didn't exist I'd have to invent 
something damn similar. :)

More importantly - it's not an either/or decision. I always recommend 
starting with the admin - use the available hooks and means of 
customization and when you really, truely hit a brick wall - then remember 
"It's just Django" - drop down to a custom view that uses the admin base 
templates and CSS and easily integrates with other admin pages. The beauty 
of this is that you can carry on using the admin for everything else where 
it still provides easy wins.

Warning people away means they are less likely to discover the many simple 
customization hooks and they are more likely to spend time reinventing the 
wheel.

If the admin was truly as limited as some make it out to be, then one of 
the many attempts to replace it would have gained momentum. I'm not saying 
it couldn't be replaced with something better - but it's far from being 
something we should cover in warnings and caveats.

Sigh. I perpetually intend to write tutorials to help demystify admin 
customization - but I've sadly perpetually failed to find the time...

On Tuesday, 9 February 2016 23:25:20 UTC, Tim Graham wrote:
>
> The introduction to the admin in the docs [0] reads:
>
> "One of the most powerful parts of Django is the automatic admin 
>> interface. It reads metadata in your model to provide a powerful and 
>> production-ready interface that content producers can immediately use to 
>> start adding content to the site."
>>
>
> I've proposed [1] changing it to:
>
> "One of the most powerful parts of Django is the automatic admin 
>> interface. It reads metadata from your models to provide a quick and 
>> rudimentary interface where trusted users can manage content on your site. 
>>
>>
>> The admin has many hooks for customization but beware of trying to use 
>> those hooks exclusively. If your needs outgrow what the admin provides, it 
>> may be simpler to write your own views. The admin’s recommended use is as 
>> an organization’s internal management tool. It’s not intended for building 
>> your entire front end around."
>>
>
> However several reviewers have made comments like "I worry that the 
> description of the Admin sells it short. The Admin is actually brilliant 
> kit and works as advertised." and "Downgrading Django's admin from 
> "powerful and production ready" to "quick and dirty [old wording]" is very 
> harsh... And I fear this will not only lower user's expectations, but also 
> dev's carefulness!"
>
> I think part of the reason I raise this is that I'm getting weary of 
> adding hook after hook for customizing every little thing. I worry we'll 
> end up with an unmaintainable mess at some point. The latest proposal that 
> has me thinking about this adds ModelAdmin.orderable_by and 
> ModelAdmin.get_orderable_by() 
> for the use case of disabling sorting of a column in the change list [2]. 
> This topic also came up in the discussion of whether or not to add 
> ModelAdmin.exclude and ModelAdmin.get_exclude() [3] (which hasn't been done 
> yet). There's also an open question about whether or not to add a view 
> permission [4]. I don't want to discuss each of these decisions on this 
> thread but rather the broader question of whether putting a lot of effort 
> in this area is a direction we should pursue. I know there have been some 
> proposals of "admin2" but realistically I think the admin has too many 
> customizations points such that superseding it with something new and 
> innovative won't be feasible from a backwards compatibility standpoint.
>
> [0] https://docs.djangoproject.com/en/dev/ref/contrib/admin/
> [1] https://github.com/django/django/pull/6104
> [2] https://github.com/django/django/pull/6107
> [3] 
> https://groups.google.com/d/topic/django-developers/WrnhmTyLHuY/discussion
> [4] 
> https://groups.google.com/d/topic/django-developers/X7YEGB9KJNc/discussion
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/26f81439-3648-40cf-9a46-fceb5ccabba1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

[Andy Baker]

Just to follow up - I think the biggest improvements I've yearned for are 
fairly simple and unlikely to break backwards compatibility:

1. Break up the remaining monolithic methods to allow easier overriding 
(this is much better nowadays but a few beasts remain)
2. More blocks in the templates or more includes - again to allow 
overriding. 

Also - If those parts of the admin that are unique to it and not merely 
aspects of ModelForms, CBVs and other generic Django features  could be 
broken out and made re-susable - then over time the admin could become 
simply an example of how more general Django features can be glued 
together. 

On Wednesday, 10 February 2016 13:55:02 UTC, Andy Baker wrote:
>
> I can't help but feel that the "admin is very rudimentary and hard to 
> customize" is perpetually overplayed by many in the community. Maybe I'm 
> suffering Stockholm Syndrome but I'd like to raise a dissenting voice.
>
> I find it the quickest and most efficient way to provide an admin 
> interface for staff users. It's remarkably easy to customize in my view 
> (and I've done a heck of a lot of it). If it didn't exist I'd have to 
> invent something damn similar. :)
>
> More importantly - it's not an either/or decision. I always recommend 
> starting with the admin - use the available hooks and means of 
> customization and when you really, truely hit a brick wall - then remember 
> "It's just Django" - drop down to a custom view that uses the admin base 
> templates and CSS and easily integrates with other admin pages. The beauty 
> of this is that you can carry on using the admin for everything else where 
> it still provides easy wins.
>
> Warning people away means they are less likely to discover the many simple 
> customization hooks and they are more likely to spend time reinventing the 
> wheel.
>
> If the admin was truly as limited as some make it out to be, then one of 
> the many attempts to replace it would have gained momentum. I'm not saying 
> it couldn't be replaced with something better - but it's far from being 
> something we should cover in warnings and caveats.
>
> Sigh. I perpetually intend to write tutorials to help demystify admin 
> customization - but I've sadly perpetually failed to find the time...
>
> On Tuesday, 9 February 2016 23:25:20 UTC, Tim Graham wrote:
>>
>> The introduction to the admin in the docs [0] reads:
>>
>> "One of the most powerful parts of Django is the automatic admin 
>>> interface. It reads metadata in your model to provide a powerful and 
>>> production-ready interface that content producers can immediately use to 
>>> start adding content to the site."
>>>
>>
>> I've proposed [1] changing it to:
>>
>> "One of the most powerful parts of Django is the automatic admin 
>>> interface. It reads metadata from your models to provide a quick and 
>>> rudimentary interface where trusted users can manage content on your site. 
>>>
>>>
>>> The admin has many hooks for customization but beware of trying to use 
>>> those hooks exclusively. If your needs outgrow what the admin provides, it 
>>> may be simpler to write your own views. The admin’s recommended use is as 
>>> an organization’s internal management tool. It’s not intended for building 
>>> your entire front end around."
>>>
>>
>> However several reviewers have made comments like "I worry that the 
>> description of the Admin sells it short. The Admin is actually brilliant 
>> kit and works as advertised." and "Downgrading Django's admin from 
>> "powerful and production ready" to "quick and dirty [old wording]" is very 
>> harsh... And I fear this will not only lower user's expectations, but also 
>> dev's carefulness!"
>>
>> I think part of the reason I raise this is that I'm getting weary of 
>> adding hook after hook for customizing every little thing. I worry we'll 
>> end up with an unmaintainable mess at some point. The latest proposal that 
>> has me thinking about this adds ModelAdmin.orderable_by and 
>> ModelAdmin.get_orderable_by() 
>> for the use case of disabling sorting of a column in the change list [2]. 
>> This topic also came up in the discussion of whether or not to add 
>> ModelAdmin.exclude and ModelAdmin.get_exclude() [3] (which hasn't been done 
>> yet). There's also an open question about whether or not to add a view 
>> permission [4]. I don't want to discuss each of these decisions on this 
>> thread but rather t

Re: thinking about the admin's scope and its description in the docs

[Andy Baker]

> As customisable as it can be, I find the problem to be it is 
a data-centric view of your system, closely tied to the database models. 

You're correct that a truly 'task-centric' UI would be a lot of effort - 
but really - how common are such interfaces in their fullest sense? In 
reality nearly every admin UI is a fairly clear mirror of the underlying 
data schema. Show me a web app and I've got a fairly good chance of 
predicting the db tables.

I suspect that what is much more common is the ability to have 
'cross-cutting concerns' - i.e. actions that involved and orchestrate 
changes over multiple tables. There are many places that you can enable 
such things without needing to twist the admin too far out of shape: 
usertools, admin actions, custom changelist columns etc etc.

I'm not claiming any of this results in the 'perfect ui' and given the 
budget - yes - a ground-up custom admin would probably be superior. But 
real-life projects are nearly always budget constrained - especially away 
from the public-facing side - and quite frankly - the Django admin has 
enabled me to complete projects that would have been financially impossible 
to develop without it.

> Perhaps a better way to think of it as the difference between 
a "management" and a "maintenance" interface. 

I'm not sure I am clear on the distinction you are making here.

> True, in a lot of cases these can be the same thing, and for 
simpler sites Admin works "just fine".  However, I've been on too many 
projects that wind up spending a lot of time and effort customising Admin 
to do things that would have been simpler in a custom view. 

This comes back to my point that it's not a binary choice. The 
admin+customization gets you 80% of the way there quickly. When you find 
something that doesn't fit nicely just add a line to urls.py and a {% 
extends "admin/base_site.html" %} to the top of your template and you've 
got the full power of Django to solve that one particular piece of the 
problem.

> Is it possible to add other views to admin?  Sure... though it's 
not clear, or well documented. 

I would argue that it's also fairly clear as it's mostly "just django". At 
its simplest an admin view is just a Django view that uses the admin base 
template. What's unclear about that? How to incorporate linkage between the 
admin-proper and custom views is fairly simple but maybe not immediately 
obvious to a beginner. The various hooks for this are fairly well 
documented although the documentation is scattered through various places 
on this rather monolithic 
page: https://docs.djangoproject.com/en/1.9/ref/contrib/admin/

A single 'common ways to customize the admin' page could go a long way to 
helping here.



On Thursday, 11 February 2016 01:33:03 UTC, Curtis Maloney wrote:
>
>
>
> On 11/02/16 00:55, Andy Baker wrote: 
> > I can't help but feel that the "admin is very rudimentary and hard to 
> > customize" is perpetually overplayed by many in the community. Maybe I'm 
> > suffering Stockholm Syndrome but I'd like to raise a dissenting voice. 
>
> I must admit I'm a large proponent of warning against getting caught up 
> in "Admin as my management console". 
>
> As customisable as it can be, I find the problem to be it is a 
> data-centric view of your system, closely tied to the database models. 
>
> IMHO a management interface for site should be a _process_ centric view, 
> abstracting away the implementation details of tables and fields. 
>
> Perhaps a better way to think of it as the difference between a 
> "management" and a "maintenance" interface. 
>
> True, in a lot of cases these can be the same thing, and for simpler 
> sites Admin works "just fine".  However, I've been on too many projects 
> that wind up spending a lot of time and effort customising Admin to do 
> things that would have been simpler in a custom view. 
>
> Worse still, I've seen projects alter their schema design to accommodate 
> Admin's limitations [like lack of nested inlines] 
>
> Is it possible to add other views to admin?  Sure... though it's not 
> clear, or well documented. 
>
> Can documentation alone overcome this problem?  I'm not convinced it can. 
>
> For some years now I've been proposing an investigation into slicing 
> Admin into two layers: a base "management interface framework" layer, 
> and "admin" built atop this framework. 
>
> Then we can keep providing the Admin we all know and love, and also make 
> it easier for people to build their own management interfaces. 
>
> However, I don't currently have the time [or admi

Re: thinking about the admin's scope and its description in the docs

[Andy Baker]

> However, we NEVER had a client that was sufficiently familiar with what a 
database is or how data modeling works for this to ever suffice. 

I've got more than two dozen non-technical clients happily using the admin. 
They also have no familiarity with data modelling but I'm not quite sure 
how that would help or hinder them. The concept of a filterable list view 
and an editable form luckily doesn't require discussing 4th normal form or 
the benefits of relational algebra ;-)

On Thursday, 11 February 2016 19:47:43 UTC, Chris Foresman wrote:
>
> FWIW, we used to tell clients that Django offers a basic admin interface 
> "for free". However, we NEVER had a client that was sufficiently familiar 
> with what a database is or how data modeling works for this to ever 
> suffice. The first thing we always do on new project is immediately disable 
> the admin and simply design APIs that allow our front-end teams to build 
> some kind of custom dashboard/admin interface.
>
> IME, the admin is "sufficient" for sysadmins or technically experienced 
> users, but in practice those are few and far between.
>
>
>
> On Thursday, February 11, 2016 at 12:08:08 PM UTC-6, 
> bliy...@rentlytics.com wrote:
>>
>> While I think it's true that a process centric workflow (wizards, or hubs 
>> anyone?) would be incredibly useful, that does not take away from the fact 
>> that the model centric admins are also incredibly useful, and time saving.  
>> It's so easy to add search, sorting, bulk actions, etc to an admin--these 
>> are things I've often spent days or weeks working on in other systems.  
>> With django it is often a matter of minutes to add these incredibly common 
>> features.  This is probably one of my favorite things about the django 
>> framework.
>>
>> On Wednesday, February 10, 2016 at 5:33:03 PM UTC-8, Curtis Maloney wrote:
>>>
>>>
>>>
>>> On 11/02/16 00:55, Andy Baker wrote: 
>>> > I can't help but feel that the "admin is very rudimentary and hard to 
>>> > customize" is perpetually overplayed by many in the community. Maybe 
>>> I'm 
>>> > suffering Stockholm Syndrome but I'd like to raise a dissenting voice. 
>>>
>>> I must admit I'm a large proponent of warning against getting caught up 
>>> in "Admin as my management console". 
>>>
>>> As customisable as it can be, I find the problem to be it is a 
>>> data-centric view of your system, closely tied to the database models. 
>>>
>>> IMHO a management interface for site should be a _process_ centric view, 
>>> abstracting away the implementation details of tables and fields. 
>>>
>>> Perhaps a better way to think of it as the difference between a 
>>> "management" and a "maintenance" interface. 
>>>
>>> True, in a lot of cases these can be the same thing, and for simpler 
>>> sites Admin works "just fine".  However, I've been on too many projects 
>>> that wind up spending a lot of time and effort customising Admin to do 
>>> things that would have been simpler in a custom view. 
>>>
>>> Worse still, I've seen projects alter their schema design to accommodate 
>>> Admin's limitations [like lack of nested inlines] 
>>>
>>> Is it possible to add other views to admin?  Sure... though it's not 
>>> clear, or well documented. 
>>>
>>> Can documentation alone overcome this problem?  I'm not convinced it 
>>> can. 
>>>
>>> For some years now I've been proposing an investigation into slicing 
>>> Admin into two layers: a base "management interface framework" layer, 
>>> and "admin" built atop this framework. 
>>>
>>> Then we can keep providing the Admin we all know and love, and also make 
>>> it easier for people to build their own management interfaces. 
>>>
>>> However, I don't currently have the time [or admin familiarity] to 
>>> undertake this work. 
>>>
>>> -- 
>>> Curtis 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d838d00a-07f4-43b8-bc72-43b0e36691d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Admin: Allow FilterSpecs to return Q-likes

[Andy Baker]

In a few cases I've had to do filtering in Python because it wasn't possible 
purely at the db level. (mainly in cases where I'm expected small result sets 
obviously). I'd like to see this remain possible with any future changes.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e2310ee2-1f8b-4581-8566-0e37390b392a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Admin: Allow FilterSpecs to return Q-likes

[Andy Baker]

Actually - my recollection was faulty. As the queryset method always has to 
return a queryset (dur) I am not sure that I'm actually doing anything that 
couldn't be expressed as a Q object. I'm just doing some funky stuff to get my 
queryset in shape.

So I suppose my question is this - are there any operations that return a 
queryset that couldn't be captured in a Q object?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5518cd9b-5765-44c1-bccf-36824f1bf552%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.