Closed PetrDlouhy closed 5 years ago
I made the charts more configurable by the Ajax control inputs, which adds much interactivity of the charts (and by the way - more dynamic criteria are working on one chart). The time aggregation is also better hadled by the inputs rather then the dashboard tabs and groups:
When I remove the dashboard groups there is not much dependency on django-admin-tools
. So I think, it would be best, if we try to implement charts also for the default django-admin
. It could bring much more attention to this project and boost further development.
I think that in that case this project would need to be renamed to something like django-admin-charts
or django-admin-stats
.
@areski What do you think about this all?
It looks amazing! I might be worried about the performance though if too much data need to be pulled in order to power the chart, but that will really depend of the usecase.
I really like to see that project being more generic and not depending of django-admin-tools
, maybe it's a good time for you to fork the project under a different name and get the deserved credits for it too.
I have added the code for django-admin
. Big advantage is, that it will need only typical django app configuration (installed apps + urls), so installation will be much easier.
@areski The page loading performance was my primary concern why I was doing this. Before this all the data for all the charts had to be ready when loading the admin page - that was quite slow in my case (about 10 charts multiplied by 4 time scales).
Now the admin page is loaded without any data, so it is very quick. All the data are loaded in subsequent ajax requests. Loading of the particular charts can be slow, if they are containing lots of data, but it doesn't slow users from interacting with admin page. In my case even quite large datasets (like 1000+ values) are loaded usually quickly enough. But of course - loading of the chart can get slow in some cases. It might be needed to add some time/size limits, possibly configurable per chart.
You are right, the fork might be the best thing to do in change of this magnitude. I will think about it, because on the other hand - everything should work without need to change DashboardStats
and DashboardStatsCriteria
configuration (and only minor change in dasboard modules).
OK so I have released this as django-admin-charts
fork. The app name for INSTALLED_APPS
stays the same, so upgrade from django-admin-tools-stats
is quite easy.
@areski Please take a look if you don't want to change any attribution or licensing info.
I will close this PR, and open a new one which just adds some information about django-admin-charts
to the README of this project (if you are OK with that).
Thanks @PetrDlouhy! I can wait to see what django-admin-charts
will become, I have the feeling the project is in the right hands :D
This is proof of concept code which loads charts by Ajax. It should fixes slow loading of admin page, has less load on server (since it is not loading other time intervals until they are requested), improve user experience, allow to change dynamic criteria without page reload, and in the future can offer many more dynamic features.
It will need some code cleaning, before it could be pulled in. Right now it renders the chart javascript by
django-nvd3
'sload_chart
tag, which is not optimal, because it sends JavaScript code and maybe it would be better to send only data. I am not sure if we can't use better library for this, or something.TODO:
django-admin-tools
admin_tools
indjango-admin
admin_tools_stats
inINSTALLED_APPS
beforeadmin_tools
anddjango.contrib.admin
(needed for overridden template)urls.py
DashboardCharts
toDashboardChart
in dashboard definition (this is not needed, because dummy class is left)admin_tools_stats
orDashboardChart(s)
class that might interfere with the changesPlease post your suggestions.