Like what is "site front end" that the admin shouldn't replace ?!
I work with business application where clients puts data in and get reports 
back... (Like Sales/Store/Client balances and stuff)
I tried to work "my front end" (after getting the bad/wrong message from 
the docs) but it was so much time and mess and so much like re-inventing 
the wheel really.

The admin have lots of capabilities that does not yet exist in any other 
parts or CBV
To name a few:
1. Inlines  (FormView is like a teenager playing in the park next to 
Spartan Hero)
2. Entry Log change message 
3. Various 3rd party support (ex: django-reversion)
4. Changelist filters / search / table sort
5. Change form (save,save and continue, save and add another)
6. Delete confirmation displaying related objects that will get deleted 
along (though sometimes big and heavy)
.. the list can easily get much bigger.

And now with custom admin sites, we can get rid of the is_staff check, get 
rid of unrelated 3rd party app registered models (which might be only 
visible to staff indeed), override the templates and have a completely new 
look .

I think the admin should be seen as the "Best django-inc" way to manipulate 
data to your database, and get advertised as such.
Not "intended to use by only management", but to anyone with access to 
add/change/delete to a model.

IMHO, If there is some enhancement to do for the admin.. i think this 
should be it, along with more documentation/ how-to's & examples.


Thank you and kind regards

On Wednesday, February 10, 2016 at 1:25:20 AM UTC+2, 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/540baeb0-7f5a-4f45-b92c-ec4ce1979972%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to