已经解决的问题
-
组件化结构
- 开发相对简单
- form,list,tree等组件,基本上能够满足页面制作的需要
- 通过直接向组件中写html,也能实现复杂的页面。
-
快速生成
- wide支持
- wide支持
-
多语言
- 简单支持,通过properties文件设置
- 简单支持,通过properties文件设置
-
结合操作权限
- 实现了操作权限,能够做到按钮级的权限控制
- 实现了操作权限,能够做到按钮级的权限控制
-
结合xresource
-
实现处理下拉、联动、属性替换等功能
-
-
Page自动注入
- 自动完成BO等Bean的注入工作,节省了配置
-
结合webx
- 能够方便的使用到webx的所有功能
-
简化的Dao
- 不再需要写一堆的Dao接口+实现了,属于shy之外的封装
- 不再需要写一堆的Dao接口+实现了,属于shy之外的封装
存在的一些的问题
-
组件模式,是否适合开发
- 数据绑定组件,组件组成页面,会不会方便大家页面的开发。
- 希望组件重用,但重用的机会并不大,并且重用的时候也并不方便
- 首先,组件重用,主要表现在wide开发的时候。但重用的地方,通常需要对组件进行修改,往往这些修改都比较大,重用的机会就相应的变小了。这是一个双面的问题,首先要看页面重用的意义在哪里?什么时候需要重用?
- 另外,如果是查询页面的增、删、改、查、详情之间的切换,是可以用一个页面完成。并且此类功能以后完全可以让系统自动生成。
- 能不能提高开发效率?
- 使用者的体会,是加速还是造成了瓶颈
- 问题是什么?是由于框架自身的缺陷,还是由于封装的不足?
- 其他的缺点
- 数据绑定组件,组件组成页面,会不会方便大家页面的开发。
-
组件未支持的功能
- 组件不支持的特殊功能怎么处理?
- 组件升级,render升级
- 直接在程序中向组件写入html,目前我们的程序中有少部分这样的代码
- 总的来说是不怎么方便,开发的时候需要了解组件目前所支持的情况,然后看应用的需求如何能用已有的功能实现。
- 不支持ajax
- 理论上可以开发支持ajax的组件,但目前还未有实践
- 理论上可以开发支持ajax的组件,但目前还未有实践
-
扩展性
- 希望组件能够很容易的扩展,并灵活组装
- 目前明显支持的不够好,虽然可以通过成对的增加组件和render的方式来扩展,但由于在框架中存在一部分硬编码的方式,导致增加组件后,需要修改一点框架代码。
- 结构上的设计缺陷
-
page问题
- 结构不够合理
- 比如页面的继承,用起来并不方便,导致页面的重用机会不多
- page,组件,field等的接口有很多地方不够合理,需要改进
- page,组件,field等的接口有很多地方不够合理,需要改进
- 生成的Base类和集成类中有很多冗余代码
- 页面属性的设置时代码过于罗嗦(一个个属性加入是否好一点),页面变化多的时候,每个地方都要写很多代码。当页面很多属性的时候,变的很恐怖。
-
render实现的问题
- 基本上是乱七八糟,并存在很多不再使用的代码,导致修改的时候会引起其他意向不到的问题
- 前期已经做了少部分改进
- 需要完善或者重写
-
DateObject的问题
- 基于Map实现的方式,有没有必要用标准的JavaBean替换
- 装载省事,如果改为JavaBean,只要这个地方修改即可
- 可以传递一些自定义的属性,改为javaBean后,可能需要特殊的实现来处理这种需求
- 存的数据都是String导致很多的转换,即使目前做了修改,从页面上进来的时候还是String,只是从db出来 的时候是对象、在get出去的时候做了判断并转换
- DataObject一直应用到了Dao层
- 这种做法是否合理,页面上的数据,部分不需要提交到dao,不过按目前的dao实现,就算提交过去也没什么影响
- 是否需要页面数据对象和Dao的数据对象分离,分离后就要做数据映射、复制或者赋值,麻烦
-
wide缺陷
-
wide存在比较多bug,使用中要比较小心,希望以后页面相关的操作,更多的能在wide中完成
- 功能不够完善
- 缺少从db直接生成的功能,开发中,很多时候还是会先把表建好,从db直接生成,开发效率会更好一些
- 汉化的工作能够直接完成,避免去修改多个地方,db的注释能够直接使用到页面上,避免重复工作
- 页面跳转等设置也能够直接完成
- 对象属性的修改能够直接体现到组件上,缺少该功能很别扭
- 能够和应用独立开,不要发布到一起
- 存贮的信息能够写入db,或者hsql之类的内存db中,并可以方便切换,更好的支持团队开发
- 制定明确的页面模板规范,统一页面风格
-
-
页面静态label的国际化方式
- 并非真正的国际化支持,只是根据服务器的语言选择,没实际意义
- 放到xresource中或者采用其他的多语言方式,更好的和wide接合,减少重复工作
- 放到xresource中或者采用其他的多语言方式,更好的和wide接合,减少重复工作
-
缺少数据权限的处理
- 权限框架支持数据权限,可能通过修改来支持,但细节问题需要权衡,比如如何接合,如何授权等等
- 权限框架支持数据权限,可能通过修改来支持,但细节问题需要权衡,比如如何接合,如何授权等等
-
项目搭建
- 整体项目的搭建模板
- 整体项目的搭建模板
框架改进的两个方向
从技术角度去升级框架,从应用角度去封装框架-
重构
- 探索更好的开发框架
-
core调整,wide加强
- 调整目前发现的不足之处
- core只提供框架相关的组装接口,带来更好的扩展性
- 支持组件以及render的简单接入
- 动态支持组件和render的绑定,给开发者更多选择,从而减少因特殊功能的要求而不得不修改core的次数。
- core只提供框架相关的组装接口,带来更好的扩展性
- 修改render实现不好的地方
- wide加强,能够支持更快的开发模式
- 比如从db直接创建应用,建立标准的增、删、改、查模型等等
- 或者能够直接生成DB相关的表,类似mda的思想,能一条线下去做好所有的事情。
- 按优先级、难易程度排序
-
模块化应用
- 通用模块
- crm的每个子系统可以通用的模块,能够方便的跟随子系统一起发布,如审批,用户、权限等后台管理模块
- 公共模块
- 系统可以共用的、并且只要作为一个系统发布的模块。这些模块,能够为所有的子系统提供服务,并且不用跟随每个系统发布,通常和业务相关性不强,如果能够很好的独立出来,作为一个独立模块维护发布,其他的应用就更单纯一些。
- 进而将不同技术实现的应用都挂在同一个portal下,已有的应用和将要开发的应用可以通过某种策略实现整合,从而可以将已有的应用一点一点的重购过来,为开发框架统一做准备