GSOC: Turn contrib.admin into a customizable management interface

[tyrion-mx]

Discussing on #django-dev with FunkyBob and others I concluded that refactoring contrib.admin to become a generic management interface (and not a model-centric one as it is now) could be a good thing, so I started a project proposal.

It still a draft and I hope to complete it in time, anyway I would like to know as much as possible what others think about it :)

Here is the link: https://gist.github.com/tyrion/537ab187f458ba1ae9e9

I have still not mentioned that I also plan to rewrite contrib.admin using class based views.

Thanks

[Riccardo Magliocchetti]

Hi Germano,

Il 24/03/2015 11:11, tyrion-mx ha scritto:
> Discussing on #django-dev with FunkyBob and others I concluded that refactoring
> contrib.admin to become a generic management interface (and not a model-centric
> one as it is now) could be a good thing, so I started a project proposal.
> It still a draft and I hope to complete it in time, anyway I would like to know
> as much as possible what others think about it :)

Cool project!

> Here is the link: https://gist.github.com/tyrion/537ab187f458ba1ae9e9

Unfortunately one cannot comment on specific lines of gists, c&p some text below.

> It is model centric and really hard to extend. For example there is no
> simple way to customize the admin homepage (which I will call dashboard from
> now on) by defining new widgets.

Please don't throw out the baby with the bath water :) It's quite cool to just
register a model in the admin to have a crud interface.

> Editing the code is required for every, even aesthetical, customization. I
> think it would be better to allow managers (i.e. non-coders) to customize the
> appearence of the admin pages as much as possible without touching the code.
> This could be accomplished by storing part of the ModelAdmin options in the
> database.

I don't agree with "even aeasthetical" bits, there are themes available that
does not touch any django code. Still there's quite a lot of annoyances, often
reported in the ticketing system.

> It is not responsive.

That is a problem indeed, i'd suggest to just opt for a grid instead of going
for a full ui framework (or least a very minimal one). Am Maintaining a
bootstrap based theme and it always end up with tons of bootstrap specific
classes on every tag thus making difficult to reuse upstream templates.

Better to coordinate with the recent css cleanup by Elky too.

A final thought is about AdminWidget, whatever you end up with please think of
something different pattern than the Form's Media class as makes it impossible
to override css / js without touching python code.

> I have still not mentioned that I also plan to rewrite contrib.admin using class
> based views.

You should well be aware of these projects, a reference of them in your proposal
would ne nice since you can possibly reuse a lot of code:
https://github.com/pydanny/django-admin2
https://github.com/AndrewIngram/django-extra-views

BTW there was a recent discussion about the admin where people suggested they
are just creating a thin rest api over models and reimplementing the ui from
scratch. A use case you may want keep into account.

thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

[Germano Gabbianelli]

On 24/03/15 11:56, Riccardo Magliocchetti wrote:
> Please don't throw out the baby with the bath water :) It's quite cool
> to just register a model in the admin to have a crud interface.

Exactly, this is super cool. I meant hard to extend to add other
"widgets" to the home that are not models. Or even to add different
views to a ModelAdmin.

>
> > Editing the code is required for every, even aesthetical,
> customization. I
> > think it would be better to allow managers (i.e. non-coders) to
> customize the
> > appearence of the admin pages as much as possible without touching
> the code.
> > This could be accomplished by storing part of the ModelAdmin options
> in the
> > database.
>
> I don't agree with "even aeasthetical" bits, there are themes
> available that does not touch any django code. Still there's quite a
> lot of annoyances, often reported in the ticketing system.
>

With these sentences I was thinking about customizing the properties of
the ModelAdmin without editing the code. For example controlling what
fields are shown in the changelist view or even controlling what models
are visible in the admin interface.

> > It is not responsive.
>
> That is a problem indeed, i'd suggest to just opt for a grid instead
> of going for a full ui framework (or least a very minimal one). Am
> Maintaining a bootstrap based theme and it always end up with tons of
> bootstrap specific classes on every tag thus making difficult to reuse
> upstream templates.
>
> Better to coordinate with the recent css cleanup by Elky too.

Thanks for the hint, I was planning to use flexbox which seems supported
by almost all browsers ( http://caniuse.com/#feat=flexbox )

> A final thought is about AdminWidget, whatever you end up with please
> think of something different pattern than the Form's Media class as
> makes it impossible to override css / js without touching python code.

This is one big problem to be honest and I don't think I would have the
time to solve it. There could also be some other student working on it,
so I am not sure about what is the best thing to do. My plan was to
ignore the problem and provide by default widgets that use only simple
js or do not use js at all, and let the user that wants to customize the
admin choose how to handle the problem, for example by using something
like django-sekizai.

>
>> I have still not mentioned that I also plan to rewrite contrib.admin
>> using class
>> based views.
>
> You should well be aware of these projects, a reference of them in
> your proposal would ne nice since you can possibly reuse a lot of code:
> https://github.com/pydanny/django-admin2
> https://github.com/AndrewIngram/django-extra-views

I am well aware of django-admin2 I also did a small patch for them, but
they use a lot of dependencies (i.e. restframework) and this makes it
almost impossible to be used as a base for contrib.admin I think.
... Unless someone decides that contrib.admin should not be included in
django anymore and have its own package (Thing that I would not
necessarily disagree with, as it would allow it to have external deps).

> BTW there was a recent discussion about the admin where people
> suggested they are just creating a thin rest api over models and
> reimplementing the ui from scratch. A use case you may want keep into
> account.

Umh, this seems to mean "throw away the admin" and start over, I would
like instead to provide also some backward-compatibility if possible. I
am going to search on the ML for this discussion anyway, thanks!

[Riccardo Magliocchetti]

Il 24/03/2015 12:37, Germano Gabbianelli ha scritto:
>
> On 24/03/15 11:56, Riccardo Magliocchetti wrote:
> With these sentences I was thinking about customizing the properties of the
> ModelAdmin without editing the code. For example controlling what fields are
> shown in the changelist view or even controlling what models are visible in the
> admin interface.

So your proposal is to store them in the db right?

>> > It is not responsive.
>>
>> That is a problem indeed, i'd suggest to just opt for a grid instead of going
>> for a full ui framework (or least a very minimal one). Am Maintaining a
>> bootstrap based theme and it always end up with tons of bootstrap specific
>> classes on every tag thus making difficult to reuse upstream templates.
>>
>> Better to coordinate with the recent css cleanup by Elky too.
> Thanks for the hint, I was planning to use flexbox which seems supported by
> almost all browsers ( http://caniuse.com/#feat=flexbox )

Uhm, missing IE9 support. It is the default browser on vista, which has extended
support until 2017 :|

>> A final thought is about AdminWidget, whatever you end up with please think of
>> something different pattern than the Form's Media class as makes it impossible
>> to override css / js without touching python code.
>
> This is one big problem to be honest and I don't think I would have the time to
> solve it. There could also be some other student working on it, so I am not sure
> about what is the best thing to do. My plan was to ignore the problem and
> provide by default widgets that use only simple js or do not use js at all, and
> let the user that wants to customize the admin choose how to handle the problem,
> for example by using something like django-sekizai.

Well usually adding js / css in templates is enough to make theme people life
easier :)

>>> I have still not mentioned that I also plan to rewrite contrib.admin using class
>>> based views.
>>
>> You should well be aware of these projects, a reference of them in your
>> proposal would ne nice since you can possibly reuse a lot of code:
>> https://github.com/pydanny/django-admin2
>> https://github.com/AndrewIngram/django-extra-views
>
> I am well aware of django-admin2 I also did a small patch for them, but they use
> a lot of dependencies (i.e. restframework) and this makes it almost impossible
> to be used as a base for contrib.admin I think.
> ... Unless someone decides that contrib.admin should not be included in django
> anymore and have its own package (Thing that I would not necessarily disagree
> with, as it would allow it to have external deps).

I didn't mean you need to follow admin2 design, i meant it's always nice to
point out related prior work

[Germano Gabbianelli]

On 24/03/15 13:06, Riccardo Magliocchetti wrote:

Il 24/03/2015 12:37, Germano Gabbianelli ha scritto:

On 24/03/15 11:56, Riccardo Magliocchetti wrote:
With these sentences I was thinking about customizing the properties of the
ModelAdmin without editing the code. For example controlling what fields are
shown in the changelist view or even controlling what models are visible in the
admin interface.

So your proposal is to store them in the db right?

Yes, or in the session maybe. I am not really sure yet what is the best way

> It is not responsive.

That is a problem indeed, i'd suggest to just opt for a grid instead of going
for a full ui framework (or least a very minimal one). Am Maintaining a
bootstrap based theme and it always end up with tons of bootstrap specific
classes on every tag thus making difficult to reuse upstream templates.

Better to coordinate with the recent css cleanup by Elky too.

Thanks for the hint, I was planning to use flexbox which seems supported by
almost all browsers ( http://caniuse.com/#feat=flexbox )

Uhm, missing IE9 support. It is the default browser on vista, which has extended support until 2017 :|

Caniuse says that IE9 share is only 1.82%. In my opinion that could be considered  negligible if the proposed solution is "future-proof" and a lot simpler than alternatives (I would have to investigate a bit here to confirm this)

[Aaron C. de Bruyn]

On Tue, Mar 24, 2015 at 9:10 AM, Germano Gabbianelli
<tyri...@gmail.com> wrote:
> Uhm, missing IE9 support. It is the default browser on vista, which has
> extended support until 2017 :|

"Beginning January 12, 2016, only the most current version of Internet
Explorer available for a supported operating system will receive
technical support and security updates."

https://support.microsoft.com/en-us/lifecycle/search?sort=PN&alpha=internet%20explorer

I'm not a Windows guy, so I'm not sure if newer versions of IE run on
Vista. If they do, it looks like we're less than a year away from IE9
being unsupported.

Then again, I know my company has clients that still have ~40% of
machines running Windows XP due to upgrade costs. ;)

-A

[Patrick Guido]

About IE 9 support it is possible to use a polyfill for flexbox, even thought this causes performance problems and/or it (the polyfill) could not implement the full spec. https://github.com/doctyper/flexie

Another options is to go mobile first even on IE 9 (eg, everything on one column), I saw an article where someone was describing this approach (for ie8), if I find the link I'll post it here. If we add some IE9 specific css it could look good.

Patrick

--
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+unsubscribe@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/CAEE%2BrGq%2Bn%2Bi5LA%2B1Fs47LY3xKCvCZ%3DZBVDjZRnB8%2BBPw%3DdyTNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Curtis Maloney]

Let's not get bogged down in minutiae just yet :)

How to implement a grid and what level of browser support is something that can be threshed out in the process.

I love the idea of a Dashboard with custom Widgets.

Allowing the existing "App list" widgets, along with new custom non-model widgets will open Admin a lot.

This idea is so good, grappelli have had it for years :p

Does this also, then, imply the need for sub-dashboards, as Admin has currently per-app?  Or would we use our new-found flexibility to, for instance, accordion-out "folders" of widgets?

And I may as well suggest allowing widgets to hint at their size [e.g.  1x1, 2x1, 1x2, etc..]

... I'll comment more when I can focus better ...

--

C

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/CAOUxZcsur_mn0q3EoXPe-QEZ1dRHYgw9jJycSUJVJqUBnyxLhQ%40mail.gmail.com.

[tyrion-mx]

On Tuesday, March 24, 2015 at 11:48:59 PM UTC+1, Curtis Maloney wrote:

Let's not get bogged down in minutiae just yet :)

How to implement a grid and what level of browser support is something that can be threshed out in the process.

I agree 

I love the idea of a Dashboard with custom Widgets.

Allowing the existing "App list" widgets, along with new custom non-model widgets will open Admin a lot.

This idea is so good, grappelli have had it for years :p

Infact I am now trying to look and understand the documentation and code of grappelli and also of django-xadmin ( https://github.com/sshwsfc/django-xadmin ).

I don't know yet how these projects implemented a dashboard, so I am going to study them a little. Anyway if you want to suggest a good architecture to implement this, please do it. 

 

Does this also, then, imply the need for sub-dashboards, as Admin has currently per-app?  Or would we use our new-found flexibility to, for instance, accordion-out "folders" of widgets?

 I am not sure I understand what you mean here. If you are talking about the possibility to have a custom dashboard for every app in the app index page (i.e. /admin/$app), it is ok for me. The only constraints now are the little time remained to write the proposal and the time available to do the GSOC.

However I think that app dashboards and widgets groups could be left out initially and added later if we want them.

 

And I may as well suggest allowing widgets to hint at their size [e.g.  1x1, 2x1, 1x2, etc..]

 Yes my idea was to put these information in the html like this, probably:

    <div class="widget" data-size="{{ widget.size }}" data-default-size="1x1" data-order="{{ widget.order }}">

where widget.size and order could come from the database or the user's session for example.
The only problem here is that we would have to decide what 1x1, 2x1 etc means (i.e. do we want a grid or do we want to leave the developers of widgets to define their own css)

I am not too expert with css, so it is not super-clear to me what would be the best way to handle this.