这里数据缩放还有一个问题需要解决,就是随着日期的增加,图表非常密集,很难看。ECharts提供了图表缩放工具DataZoom,
您可以通过拖动和更改大小来控制数据的显示范围。配置很简单。只需将其添加到图表的配置中。例如,我的写作方法是:
数据缩放: {
类型: '滑块',
start: 60,
end: 100
},
详细数据图表显示出来后,想了解某一天某一组的详细打卡数据怎么办?
为了便于使用,使用EChart的事件机制,当单击直方图时,会显示详细信息。
实现很简单,就是一个chart对象加载一个事件,其中Ajax8用来加载和显示数据:
myChart.on('click ',' series ',function(params) {
console . log(params);
$.ajax({
url: '/api/teamcheckdetail ',
数据: {
team: params.seriesName,
date: params.name
}
}).完成(功能(响应){
data=response.data
$('#detail ')。jsGrid({
编辑:假,
排序:错误,
自动加载:错误,
data:数据,
字段: {
名称' : '名称':
标题' : '昵称'
}, {
姓名' : '检查':
标题' : '打卡'
}
});
});
});
这里,最复杂的打卡页面完成了。看效果:
打卡率数据列表成员数据、组长数据、计费数据都是以数据表的形式展现,采用jsGrid9框架,主要是方便易用。
在页面上定义一个div,设置id,然后用jsGrid方法渲染一些,就简单了。
其实在上一节,我们也看到了如何渲染。我们需要做的是定义后台API接口,通过Ajax加载数据:
$('#jsGrid ')。jsGrid({
身高: '600 ',
宽度: '100% ',
编辑:假,
排序:错误,
自动加载:真,
控制器: {
loadData:函数(){
var d=$。延期();
$.ajax({
url: '/api/memberdata ',
}).完成(功能(响应){
d . resolve(response . data);
});
返回d . promise();
}
},
Fields: {'name' 3360' group ',type: 'text'},
{'name': '昵称',type: '文本' },
{ '姓名' : '帐单',键入: '文本' },
{'name':' share ',type: 'text'},
{'name': '打卡',type: 'text'},
{'name': '提问',type: 'text'},
{'name': '答案排序',type: 'text'},
{'name':' integral ',type: 'text'},
});
然后组长数据和计费数据也差不多,这里就不赘述了。
数据接口Flask实现后台接口,非常简单。在接口对应方法之前加一句注释11就行了,比如打卡率的接口:
@app.route('/')
@app.route('/check_rate ')
定义检查率():
data=data source . show _ check _ rate(rtype=' dict ')
Ret='日期','第一组','第二组','第三组','第四组','第五组'
对于数据:中的d
行=
对于d:中的k
row.append(d)
ret.append(行)
render _ template(' check _ rate . html ',title=' punch rate ',data=ret)
打卡页面的数据是在合成响应页面时提供的,有些页面需要前台通过Ajax获取。界面怎么写?
以获取会员数据为例:
@app.route('/api/memberdata ')
def api_memberdata():
data={ ' data ' : data source . show _ member _ score(rtype=' dict ')}
返回jsonify(数据)
然后,其他页面响应和数据响应接口也差不多。有关更详细的代码,请参见代码示例。
部署的主要开发工作完成后,就可以部署了。
我之前写过部署Flask12,用uWSGI,只是抄袭。
如果没有git或者svn的代码管理,只需要复制到服务器上,安装Flask,就可以启动了。
python app.py
没问题,配置Nginx13的反向代理3360。
服务器{
听80;
服务器名stc.example.com;
access _ log/var/log/nginx/access _ STC . log main;
位置/{
proxy _ buffers 8 1024k
代理_缓冲_大小1024k
proxy _ pass http://127 . 0 . 0 . 3605000;
}
}
配置完成后,重启Nginx服务。如果没有问题,可以通过设置的域名访问。
维护部署完成,但不是真正完成,运维还是要做的。
以本项目为例,运维工作主要包括两部分:
只有不断处理数据,才能及时更新数据。这项工作对Web系统是支持性的,所以Web系统没有必要负责。
在Linux系统上,有一个crontab15命令,可以用作计时数据。好处是开发量小,不会因为Web系统的问题耽误数据处理。
服务器维护是为了保证服务器不会因为异常而停止工作。一般uWSGI这样的服务器都有自维护功能。如果他们没有被使用,他们需要自己处理。例如,编写一个监控脚本,当发现服务器不工作时,重新启动服务并发送通知。
强烈建议使用安全的Web服务器,尤其是在生产环境中。
综上所述,系统已经建成。我不再需要每天花时间在生成报告上,所以我可以花更多的时间在更重要的事情上。
如果你仔细阅读,你会发现每一条知识和技术都很简单,但是如何拼接这些简单的点,需要大量的知识记录和经验。
我之所以能这样做,是因为这里的长期输出是从最基础的Web系统开始的,我一点一点了解整个Web系统所需要的基础。一个系统需要完成的时候,大部分来自于平时的积累。
希望这篇文章能对你有所启发。一切都来自于不断的积累。小心点!
参考文献[代码获取方式]