Eova用户答疑-念小山

原创
2015/06/17 18:39
阅读数 1.2K

最近,利用EOVA开发了一个科研人员日常管理助手V1.0版。

该版本主要针对科研人员日常的项目经费相关业务展开,具体功能包括:

(1)团队及项目相关人员信息管理;

(2)项目类型管理;

(3)经费科目管理;

(4)项目基本信息管理;

(5)项目预算管理;

(6)针对项目参与人员经费使用划分的人员经费分配管理;

(7)收支流水账记账管理;

(8)相关查询统计分析,包括人员经费使用情况统计、项目预算执行情况统计、项目经费收支情况统计等。

 

该软件V1.0一定程度地解决了科研单位项目团队的项目经费使用管理问题,彻底解决了离开财务部门,经费收支对于团队内部成为一笔糊涂账的现状与问题。

 

开发周期:熟悉EOVA + 数据库设计 + 开发: 8个小时完成。当然开发人员对于业务和数据库部分比较熟悉,这在一定程度上起了作用。

评价:对于基本信息管理非常方便。

 

从开发角度建议后期版本改进的主要问题:

(1)在可解决业务问题的前提下,尽量使用与已有前端本身的控件,比如easyui的datetimebox,numberbox,combobox等,而减少自行开发控件(eovatime之类的)的必要,后者对于维护并没有实质性贡献。我这边试了,easyui的datetimebox,numberbox,combobox都可以很好地嵌入到datagrid里面。

Eova 自定义EasyUI Form控件的原因如下:

1.EasyUI 非开源,并且需要授权,并且样式丑,迟早会被淘汰

2.EasyUI 代码是以前端开发者思维实现的,不利于Java服务端开发人员的理解。

3.EasyUI 并未提供 例如,查找框,并且很难拓展,可能是本人JS水平有限(大部分服务端开发者都专注于服务端开发,JS都一般,中不中)。

4.Eova自定义Form,一方面为了统一样式,一方面为了后续业务扩展做铺垫。

eg.在实现 Grid Cell Edit 的时候,有一个需求是根据文本内容来逆选下拉项,EasyUI 的下拉框默认是根据Value来选中下拉项的。

 

(2)数据类型的细化:数据类型绝对不止字符、数字、时间三类;数字类型包含整型和浮点型等多种,浮点型还有精读要求;这在进行数据校验时都有其用途;

这个后续可以根据实用性进行完善,目前仅提供 字符 数字 时间,常规的业务都能够支撑了,其它的类型都可以用字符串来代替然后配合正则。

之前提供了数字框,后面又删了,类型多了 维护就麻烦了 不符合通用的原则。

这个会根据用户实际使用进行调整...具体情况具体分析!

 

(3)类似于public static final String TYPE_TEXT = "文本框";这种程序写作方式,对于后期维护带来了不少麻烦。程序里面大量直接基于  == "文本框" 的判断提高了程序可读性,但不符合可扩展性的要求。加入你要将软件国际化,怎么办?既然你定义了那么多的全局变量,那就用全局变量来判断了。在数据存储时,空间类型也不该被存储为“文本框”之类的中文,同理,你面对的国际化客户可能不喜欢这种模式。

Eova的定位是国产开源软件,各种设定均正对天朝的用户习惯,暂时不考虑国际化,如果有需求的可以定制,改动也不会很大!

国际化 要变的不仅仅是 文字,各种操作,体验都需调整。

 

(4)代码还是可以进一步简化,一些模型的存在着实没有实际意义。比如User类、Role类、Btn类、RoleBtn类。既然你是基于元数据的,这些模型同样可以在Object和Field(Eova用的是Item,这个词语实际上没有实质含义)的基础上自动化。

Eova是基于OOP 然后才是基于元数据。后续扩展中 Java Bean 会起到重要作用,目前业务简单,当然没有任何作用,这就是为什么JFinal要主推 Model 然后才是 Record操作。

 

(5)目前在对象管理和字段管理方面,可做的更灵活,比如编辑框的大小可作为Object的属性之一,让用户自己管理,因为有些对象字段较少,编辑对话框可以小点;有些比较大,则可以定义得大点;字段管理,需要引入 最大字符长度、数据精读以及最大值、最小值、数据范围等check constraints。这部分check constraints与后期的数据校验密切相关。

校验目前,只提供的 最简单的两个属性,下一个版本 会强化,支持常用校验,正则,异步

 

(6)目前对于错误的捕获和解读仍然处于开发模式,使用中,如果用户看到的是各种Jfinal.activeRecord错误,那对于开发团队来说,是一种灾难。

后面会设定成可配置的,INFO DEBUG

 

(7)当元数据导入后,菜单管理默认添加查询功能,但很多时候查询是有范围限制的,比如部门经理可以查该部门人员的所有信息,部门人员只能查自己的,等等,对象的过滤表达式是否需要考虑如何开放查询范围的问题。

后续会强化表达式,以支持 环境变量 虚拟变量 等多种高级用法,以满足复杂业务的实现。

 

(9)有关Session可以开放,将Session可能涉及的变量内容开放给用户自行定义,比如Session("user")、Session("department")等,因为这部分内容很可能成为(5)中查询范围的输入参数。

Session V1.2 已经开放,业务拦截器里 可以获取 Controller,关于Controller的一切都可以随意操作,具体参考JFinal手册

 

(10)Master-Detail模式、Tree + Grid模式后期可以考虑。

不用考虑,一定会有,我保证,已经在计划列表了

 

总结:非常感谢念小山对Eova的支持和协助,能实际使用,并且提出这么多专业的问题,真的是棒棒嗒!值得大家膜拜!也希望大家多多提问,我一定会一一解答。不怕有问题,就怕无人问津!

展开阅读全文
打赏
1
1 收藏
分享
加载中
Eova博主

引用来自“猪哥孔明”的评论

刚看了1.5 树形的还没加啊?
1.6提供Tree
2016/01/27 09:41
回复
举报
刚看了1.5 树形的还没加啊?
2016/01/26 17:01
回复
举报
刚看了1.5 树形的还没加啊?
2016/01/26 17:01
回复
举报
在想捐多少合适呢?
2016/01/26 16:59
回复
举报
2016/01/21 11:20
回复
举报
Eova博主

引用来自“shinwell”的评论

很看好这个开源项目,准备用在产品中了。谢谢老板!!
这个版本 骨架基本已经完成,可以开始应用了,早用早爽!Eova和大家一起成长!虽然路上也会遇到很多坑,但是会和大家一起迈过!
2015/08/17 16:01
回复
举报
很看好这个开源项目,准备用在产品中了。谢谢老板!!
2015/08/17 11:13
回复
举报
很好的体验反馈,很棒的应答,支持Eova!
2015/07/10 23:22
回复
举报
嘿嘿哈嘿,顶顶顶53
2015/06/17 18:49
回复
举报
更多评论
打赏
9 评论
1 收藏
1
分享
返回顶部
顶部