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

[James Pic]

On Tue, Mar 15, 2016 at 1:59 AM, Ramez Ashraf  wrote:
>
> 1. Inlines  (FormView is like a teenager playing in the park next to Spartan
> Hero)

There are inlinemodelformsets you can use outside the admin.

> 2. Entry Log change message

django-activity-stream or even django-reversion

> 3. Various 3rd party support (ex: django-reversion)

It's not that the admin supports it, it's that django-reversion
provides templates which support the admin.

> 4. Changelist filters / search / table sort

django-filter, django-haystack, django-tables2

> 5. Change form (save,save and continue, save and add another)

You can make your form view mixin with this

> 6. Delete confirmation displaying related objects that will get deleted
> along (though sometimes big and heavy)

Delete view requires confirmation - it probably requires post at least.

Hope this helps

Best

James

-- 
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/CALC3KaeUJ62y5b%3DshH3jW2GkVe6fiXVxW-57aTqBE7ytWGenoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ramez Ashraf]

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.

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

[Aymeric Augustin]

+1

-- 
Aymeric.

> On 17 févr. 2016, at 18:16, Marc Tamlyn  wrote:
> 
> That looks like a good balanced message to me.
> 
> On 17 February 2016 at 16:57, Tim Graham  > wrote:
> Here's another try for the docs:
> 
> One of the most powerful parts of Django is the automatic admin interface. It
> reads metadata from your models to provide a quick, model-centric interface
> where trusted users can manage content on your site. The admin's recommended
> use is limited to an organization's internal management tool. It's not 
> intended
> for building your entire front end around.
> 
> The admin has many hooks for customization, but beware of trying to use those
> hooks exclusively. If you need to provide a more process-centric interface
> that abstracts away the implementation details of database tables and fields,
> then it's probably time to write your own views.
> 
> 
> On Friday, February 12, 2016 at 4:30:07 AM UTC-5, Andy Baker wrote:
> > 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 

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

[Marc Tamlyn]

That looks like a good balanced message to me.

On 17 February 2016 at 16:57, Tim Graham  wrote:

> Here's another try for the docs:
>
> One of the most powerful parts of Django is the automatic admin interface.
> It
> reads metadata from your models to provide a quick, model-centric interface
> where trusted users can manage content on your site. The admin's
> recommended
> use is limited to an organization's internal management tool. It's not
> intended
> for building your entire front end around.
>
> The admin has many hooks for customization, but beware of trying to use
> those
> hooks exclusively. If you need to provide a more process-centric interface
> that abstracts away the implementation details of database tables and
> fields,
> then it's probably time to write your own views.
>
>
> On Friday, February 12, 2016 at 4:30:07 AM UTC-5, Andy Baker wrote:
>>
>> > 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 

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

[Tim Graham]

Here's another try for the docs:

One of the most powerful parts of Django is the automatic admin interface. 
It
reads metadata from your models to provide a quick, model-centric interface
where trusted users can manage content on your site. The admin's recommended
use is limited to an organization's internal management tool. It's not 
intended
for building your entire front end around.

The admin has many hooks for customization, but beware of trying to use 
those
hooks exclusively. If you need to provide a more process-centric interface
that abstracts away the implementation details of database tables and 
fields,
then it's probably time to write your own views.

On Friday, February 12, 2016 at 4:30:07 AM UTC-5, Andy Baker wrote:
>
> > 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 

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.

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

[Curtis Maloney]

On 11/02/16 20:11, Andy Baker wrote:

 > 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 think this is a matter of scale... for many small to medium scale 
apps, you can run close to the schema.  But for some of the large 
projects I've worked on, we really needed to hide a lot of complexity 
from the users.



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 absolutely agree with this.  Again, for the cases where admin fits, it 
works well.  But going beyond that, there's not a lot of clarity in how 
to fit in with it.



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.


Unfortunately, what I've seen time and again is when people finally hit 
the wall in admin customisation, they're too invested in admin to go any 
other path.  So I always advise caution in this - make sure people go in 
with "eyes open".



 > 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/


Well, part of the problem is, I believe, that admin is structured very 
differently to almost every other part of Django.  It follows that has 
been called a "publisher" pattern, where all related views, etc, for a 
given resource are provided in a single class (more or less).


This monolithic nature is quite different to the "collection of views in 
a module" approach used elsewhere.


I'm not saying this is wrong, but it does mean you have to learn a whole 
new approach in order to work with it on anything beyond a superficial 
level.



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


+1

--
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/56BD14D1.4020505%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

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

[Chris Foresman]

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/7fe074dc-dfbe-484c-8a2c-75f1fa098545%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

[bliyanage]

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/26ee6e6b-f5dd-4959-a8d9-d1be6acfad4b%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]

> 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 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 

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

[Curtis Maloney]

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/56BBE4BB.3060805%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

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

[Dheerendra Rathor]

On Wed, 10 Feb 2016 at 13: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 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...
>

It comes to my  mind many times to create a video tutorial for advance
Django including customizing admin and other advance part of Django like
complex querysets (with F, Q etc).
We can work together on this to create nice tutorials.

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 

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 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] 
>> 

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

[Dheerendra Rathor]

On Tue, 9 Feb 2016 at 23:25 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.
>
>
How about quick and powerful?

> 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."
>>
> What I have understood from using admin for years is that customizing
admin is really tough for new users, but for power users admin is a really
handy tool. I've written way complex user permission handling using admin
tool which could have given a hard time if written in normal django views.


> 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.
>
> Yes admin do provide customization for every little thing. IMHO, the power
of admin lies in this. A new admin might work but I fear power users won't
like it if it does not provide all those little customization like current
admin.

> [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/72ecc667-1dba-432e-a749-dca214fa77b5%40googlegroups.com
> 
> .
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAByqUgjZBxpzM5cXevF5a3Pcmj-Z5wQd_%3D8uwnvkfFqrMv%3D7nw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Riccardo Magliocchetti]

Hello,

Il 10/02/2016 00:25, Tim Graham ha scritto:

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.


s/rudimentary/basic/ maybe? As a non native english speaker rudimentary does not 
sound positive.




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."


To me that the intended use of the admin as internal management tools has been 
kinda obvious given it's accessible to user flagged as staff.


[snip]

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.


Wasn't the plan to revise these customizations points and thus probably breaking 
backwards compatibility anyway?



--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/56BAF8E2.3020706%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Russell Keith-Magee]

On Wed, Feb 10, 2016 at 7:25 AM, 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.
>

“At some point”? Yes… some point long ago :-)


> 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.
>
> For me, it depends on how much time and energy you’re spending on these
enhancements.

I agree that a new admin is needed, and at this point, it’s highly unlikely
that it will be backwards compatible. The best we could hope for is a solid
migration guide, or maybe some sort of compatibility shim.

However, in the meantime, for better or worse, we have an admin, and people
are using it. If there’s a feature someone wants to add, and they’re
sufficiently motivated to develop a patch, and that patch doesn’t make
things *worse* (i.e., it’s a well designed feature that doesn’t cause
problems), and the review process isn’t excessively onerous (i.e., you’re
not having to spend multiple hours reviewing and re-reviewing a patch to
make it trunk ready) then I we should accept the patch.

Yours,
Russ Magee %-)

-- 
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/CAJxq849Qo%3Djp6MdzSr84EBLPWKw7w_Z%3Dv7BCHoNnDR4fQ-i39Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tim Graham]

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/72ecc667-1dba-432e-a749-dca214fa77b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.