像了解爱人一样了解ExtJs
2008-03-11 10:34
260 查看
投入项目前先做好功课
EXT无疑是最近前端开发最受关注的话题。在近一年的YUI-Ext 0.30/ExtJS 1.X开发之后,上周五ExtJS又推出它的升级版本2.0,而更多的开发也参与到前端开发这一领域来。 在Web2.0/Enterprise2.0声势、日益强调用户体验的情况下,选择EXT是否明智?这些都需要开发者慎重决策。
项目参与EXT切忌盲目
据资深IT分析人士表示,目前界业内的Ajax热浪,一方面是由于2005年以来的Google一线产品使人带来极大的用户体验,另一方面来自对旧事物新改造的关注。
第一只“出海”的YUI-Ext只是作者Jack打算对基于BSD协议的Yahoo!UI库进行自定义的扩展,但后来一度风头盖过其父辈YUI,足以说明大家对它的热情,很多人把它投入项目人并不十分了解它。分析人士打了一比喻:就好比尚未谋面, 并不了解一个人的家庭、教育、品行等背景,只因为他有一副精致漂亮的外观,就对其陷入了疯狂的倾慕之中。因此分析人士建议,在投入项目前,要认真仔细地了解EXT的内在原理和与其他Ajax库不同地方。
Ext的UI组件模型和开发理念脱胎成型于Yahoo组件库YUI ,并为开发者屏蔽了大量跨浏览器方面的处理。相对来说,EXT要比开发者直接针对DOM、W3C对象模型开发UI组件轻松。
Ajax库各有不同
目前业界中Ajax库的主要是服务端系(服务端生产JS代码)和原生系(直接浏览器的JS代码控制),有消息说今后各JavaScript库团队也准备推出UI产品。不同的“家族”背景,决定了它们开发的Ajax库应用与风格的不同。
从数目上来看,目前服务端系的Ajax库如(DWR、GWT、MS Ajax.Net)占据相当的市场份额,是较多用户的选择。
原生系的Ajax库近期也迅猛发展,在ExtJS顺利试水之后,jQuery的UI库也已经发行,Mootools则在年底之前推出,其它元老如Dojo也在积极筹备新版1.0。
原生系的Ajax开发在我国还是个新生事物,目前推出的Ajax库IDE支持方面普遍不足,需要大量的手工编码,各种浏览器之间的调试工具也不尽相同,属于较小开发者所掌握的技能,风险和人力成本都会相对比较高。
今后如果各JavaScript库团队推出自己的UI组件库,--由于大多数是开源的项目,因此其文档是否完善,案例、范例是否足够多,是否易于使用,都属于相关的选型指标。相对来说其社区越旺盛,其风险也就越小。
研究不同类别的Ajax库,开发者可以知道它的投入项目价值和怎么迎合自身开发需求,而各测试报告、DEMO演示则比较可以帮助开发者分析风险收益,进而根据客户需求目的、预期和风险承受能力,来选择心仪的一个库。比如为快速将数据生成到前端,适合选择服务端系的产品; 而追求较佳的用户体验,对界面设计,用户交互操作有一定要求者,则可以EXT、Dojo专业UI库来实现。而希望学习成本低的开发者,可以使用微软的Ajax.Net库,允许方便地“可视化编程”。
决定实施之前多作比较
实际上,目前关于是否应该封装EXT“控件”存在着两种完全不同的意见。已有实践开发EXT经验的朋友甚至原作者Jack都表示,手工JS编码更适合EXT开发,这样各组件的耦合颗粒度更细,项目整体的灵活度机会高。而另一派的观点则认为,在Java/.Net的大背景下,多数开发者希望利用IDE或类似VB的GUI“画出”控件这样强大的支持来解决表示层的方案,以提供工作效率;另一方面,大量JavaScript投入项目产生,开发者会因JavaScript另外一本质---基于函数式编程(LISP但是C语法系)的困惑而对项目设计而大打折扣,我们没有道理离开熟悉的领域到陌生的地方去冒险。
由于绝大多数EXT产品的都在实践和测试之中,因此,国内的开发者确实需要慎重思考,认真研读相关JS库的文档和资料,并将其与自己熟悉的JS库比较,确实了解其风险与客户需求再作决定。
另外对于打算购买商业许可的用户,开发者还需要注意不同的商业的价格是不一样的。每种许可一般分为仅源码、源码+技术支持和1.x的升级。而企业级的EXT许可证的门槛更高,大多在两万元人民币以上。
许可解读
EXT使用双重协议,其中之一是基于LGPL 3.0协议进行许可,另外是针对技术支持的商业许可。
而很多用户对EXT协议的理解目前暂时还是“雾里看花”。
按照官方网站的有关解析,如果商业使用不付费也是可以的,只要符合LGPL 3.0的开源协议。
“Are using Ext in a commercial application that is not a software development library or toolkit, you will meet LGPL requirements and you do not wish to support the project”
“如果您应用Ext在一个商业应用中(即商业应用不是作为软件开发库或工具箱,一般可以认为是第三方组件),您可以参见LGPL要求(如果你不想支持Ext项目)”。
本文转载自 :www.javaeye.com,作者:sp42
EXT无疑是最近前端开发最受关注的话题。在近一年的YUI-Ext 0.30/ExtJS 1.X开发之后,上周五ExtJS又推出它的升级版本2.0,而更多的开发也参与到前端开发这一领域来。 在Web2.0/Enterprise2.0声势、日益强调用户体验的情况下,选择EXT是否明智?这些都需要开发者慎重决策。
项目参与EXT切忌盲目
据资深IT分析人士表示,目前界业内的Ajax热浪,一方面是由于2005年以来的Google一线产品使人带来极大的用户体验,另一方面来自对旧事物新改造的关注。
第一只“出海”的YUI-Ext只是作者Jack打算对基于BSD协议的Yahoo!UI库进行自定义的扩展,但后来一度风头盖过其父辈YUI,足以说明大家对它的热情,很多人把它投入项目人并不十分了解它。分析人士打了一比喻:就好比尚未谋面, 并不了解一个人的家庭、教育、品行等背景,只因为他有一副精致漂亮的外观,就对其陷入了疯狂的倾慕之中。因此分析人士建议,在投入项目前,要认真仔细地了解EXT的内在原理和与其他Ajax库不同地方。
Ext的UI组件模型和开发理念脱胎成型于Yahoo组件库YUI ,并为开发者屏蔽了大量跨浏览器方面的处理。相对来说,EXT要比开发者直接针对DOM、W3C对象模型开发UI组件轻松。
Ajax库各有不同
目前业界中Ajax库的主要是服务端系(服务端生产JS代码)和原生系(直接浏览器的JS代码控制),有消息说今后各JavaScript库团队也准备推出UI产品。不同的“家族”背景,决定了它们开发的Ajax库应用与风格的不同。
从数目上来看,目前服务端系的Ajax库如(DWR、GWT、MS Ajax.Net)占据相当的市场份额,是较多用户的选择。
原生系的Ajax库近期也迅猛发展,在ExtJS顺利试水之后,jQuery的UI库也已经发行,Mootools则在年底之前推出,其它元老如Dojo也在积极筹备新版1.0。
原生系的Ajax开发在我国还是个新生事物,目前推出的Ajax库IDE支持方面普遍不足,需要大量的手工编码,各种浏览器之间的调试工具也不尽相同,属于较小开发者所掌握的技能,风险和人力成本都会相对比较高。
今后如果各JavaScript库团队推出自己的UI组件库,--由于大多数是开源的项目,因此其文档是否完善,案例、范例是否足够多,是否易于使用,都属于相关的选型指标。相对来说其社区越旺盛,其风险也就越小。
研究不同类别的Ajax库,开发者可以知道它的投入项目价值和怎么迎合自身开发需求,而各测试报告、DEMO演示则比较可以帮助开发者分析风险收益,进而根据客户需求目的、预期和风险承受能力,来选择心仪的一个库。比如为快速将数据生成到前端,适合选择服务端系的产品; 而追求较佳的用户体验,对界面设计,用户交互操作有一定要求者,则可以EXT、Dojo专业UI库来实现。而希望学习成本低的开发者,可以使用微软的Ajax.Net库,允许方便地“可视化编程”。
决定实施之前多作比较
实际上,目前关于是否应该封装EXT“控件”存在着两种完全不同的意见。已有实践开发EXT经验的朋友甚至原作者Jack都表示,手工JS编码更适合EXT开发,这样各组件的耦合颗粒度更细,项目整体的灵活度机会高。而另一派的观点则认为,在Java/.Net的大背景下,多数开发者希望利用IDE或类似VB的GUI“画出”控件这样强大的支持来解决表示层的方案,以提供工作效率;另一方面,大量JavaScript投入项目产生,开发者会因JavaScript另外一本质---基于函数式编程(LISP但是C语法系)的困惑而对项目设计而大打折扣,我们没有道理离开熟悉的领域到陌生的地方去冒险。
由于绝大多数EXT产品的都在实践和测试之中,因此,国内的开发者确实需要慎重思考,认真研读相关JS库的文档和资料,并将其与自己熟悉的JS库比较,确实了解其风险与客户需求再作决定。
另外对于打算购买商业许可的用户,开发者还需要注意不同的商业的价格是不一样的。每种许可一般分为仅源码、源码+技术支持和1.x的升级。而企业级的EXT许可证的门槛更高,大多在两万元人民币以上。
许可解读
EXT使用双重协议,其中之一是基于LGPL 3.0协议进行许可,另外是针对技术支持的商业许可。
而很多用户对EXT协议的理解目前暂时还是“雾里看花”。
按照官方网站的有关解析,如果商业使用不付费也是可以的,只要符合LGPL 3.0的开源协议。
“Are using Ext in a commercial application that is not a software development library or toolkit, you will meet LGPL requirements and you do not wish to support the project”
“如果您应用Ext在一个商业应用中(即商业应用不是作为软件开发库或工具箱,一般可以认为是第三方组件),您可以参见LGPL要求(如果你不想支持Ext项目)”。
本文转载自 :www.javaeye.com,作者:sp42
相关文章推荐
- anjie_sheng:窃以为专注于appstore中国区收费版本的公司都是神一样的存在……//@刘奇申: 只有业内人才能了解啊,呵呵//@吴刚: 他给我看的是他们基于国内的分析报表,我也惊讶ipho
- ExtJs中实现tree节点,全部是单击展开和收缩效果,和收藏夹点击功能一样
- extjs了解
- ExtJS初探:了解 Ext Core
- 啥时候能做到像编译器一样了解C++?
- Eclipse Javascript插件,像写Java一样写JS —— Spket,支持ExtJS
- ExtJS了解
- 学习总结之EXTJS相关了解和问题解决篇
- Extjs系列篇(2)—-初步了解
- SpringMvc如何学习框架技术? 就像如上的图示一样,先掌握新技术的体系流程图。在快速弄明白程序执行流程后,在使用过程中 了解细节。
- 学extjs已经了解基本了,可以进行项目开发,把总结的一些小点列出来一下 --转载
- ExtJS初接触 —— 了解 Ext Core
- Eclipse Javascript插件,像写Java一样写JS —— Spket,支持ExtJS
- ExtJS初接触 —— 了解 Ext Core
- 【开发过程问题汇总系列】【ExtJS 界面开发问题】新增和修改界面控件的id命名一样导致界面显示错乱的问题
- Eclipse Javascript插件,像写Java一样写JS —— Spket,支持ExtJS
- 神一样的崇拜这个女人...打破了我对我们苦b程序员极限的了解
- 帮助曾经像自己一样的小白,快速了解hog和svm,从而学会运用这两个算法来做些简单的行人检测
- Ext JS百强应用: 要用EXTJS,先了解javascript 的oop--第5强
- Extjs开始进行了解你