序
言
2010年4月1日17点50分,JAGO UI Framework库诞生了!
虽然只有jquery.js reset.css jago.js
menu.js寥寥几个文件,还挂靠在admin-webapp项目下,但是已经可以宣告JAGO研发团队长达半年无自主研发的UI库的历史终结!
让我们记住这一群富有激情和理想的筒子们 Spark,畅雅轩主,Anna,Maggie,Cyrus
开
发理念
为
什么要开发一个UI Framework
互联网上已经有很多很优秀的UI组件,为什么不直接拿过来使用,还要大费周折自己开发?其实原因有下
1,他们是UI Library,不是UI Framework,至于Library和Framework的区别,可以参考这个PPT scalable-javascript-application-architecture
和wiki文章(网
摘)如何量身打造一个前端框架
2,提供快速,可维护的Framework,不带来因学习,维护,人员变动带来的人力成本!Framework为项目而生,除了提供基础组件,
如Tree,Grid,Tab,Message之类,还提供和项目密切相关的业务组件,就广告推送项目而已,就提供了
PcbarSelect IntrestSelect
StaffTree,在这些组件的支持下,我们可爱的JAVA程序员们,再也不用烦扰负责的js写法以及和负责后台通讯
3,专业化的分工,开发的趋势应该是前后端开发分离,每一个领域都需要最精通的人负责,当然,也需要对其他领域略懂1,2...沟通也是需要成本
的!
JUI
Framework的前世
2007,只是基于ext1.0的一个grid组件封装版本,目的是为浸淫在JAVA世界的程序员提供不需要JS就能实现Grid效果的小东西,这个算不
是Framework,更算不上Widget..
2008-2009年间,基于ext和yui不断折腾做一些所谓的wigets,windows
style的desktop,勉强来说可以算是widget library,但是和Framework一点关系没有
概括的来说 JUI Framework先后处于以下阶段
使用组件 -> 封装组件 -> 修改组件 -> DIY底层+组件 -> 基于jslibray + DIY组件
-> 工程化管理组件
JUI
Framework的今生
目前似乎又走回了组件重新开发的老路子,但是使用的理念已经大有不同
1,高内聚,低耦合
2,unobtrusive javascript
3,闭包,function的特性大量使用
以这个理念
先后开发并交付了Combobox,PcbarSelect,IntrestSelect,Grid,Tab,Tree组件
正在开发的有StaffTree(员工树),Calendar(支持农历,日期+时间的组合选择)
准备开发的有Message等(组件有很多,但是最适合项目开发的还不是特别明确)
其中值得一提的是引入了bussiness componet这一业务组件的理念
对于业务组件,我们的看法是:
1,业务组件可以基于基础组件(如Grid,Tree等)开发,也可以完全独立
2,业务组件封装了后台数据及相关的配置,使得程序员开发简化
3,业务组件依赖于项目
如 网吧列表组件 PcbarSelect
在以前的做法,就将Tree提供给Java程序员后,就再也不管,让Java程序员自己实现一个弹出层 带来学习成本和维护成本
现在将整体作为控件
还有就是员工树
这是一个典型的2张表构造的树,并且还夹杂一次性load数据和分批load数据的技术特性,如果完全暴露给java程序员,估计会死人=_=!
现在就将这个封装起来,形成一个StaffTree,暴露了一个非常整洁的接口给使用者
JUI
Framework的未来
又到了I have a dream时间：)
就我个人而言,希望将来的JUI Framework是
1,每个组件都可以动态加载
2,实现组件的oop机制
3,有一个完善的开发体系和测试体系辅助组件开发以及重构
4,组件之间的调用高度解耦
5,最重要的一点,也是最值钱的一点:要多laf有多laf