最近,利用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的支持和协助,能实际使用,并且提出这么多专业的问题,真的是棒棒嗒!值得大家膜拜!也希望大家多多提问,我一定会一一解答。不怕有问题,就怕无人问津!