像了解爱人一样了解ExtJs

投入项目前先做好功课 

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和Java平台上Swing两者，并为开发者屏蔽了大量跨浏览器方面的处理。相对来说，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项目）”。

评论

11 楼 sp42 2007-11-16  

补充一下，Jack本人是反对将UI写成Tag Language的。

引用

Why try to write an app in a tag language? You end up with something very cumbersome and difficult to maintain. Why write the UI in Java at all when JavaScript can be so much faster to develop with?

详见：
http://extjs.com/forum/showthread.php?t=5730

10 楼 WWQQ 2007-10-24  

这个标题怎么那么熟悉．．．
像了解爱人一样了解ie ->精华
像了解爱人一样了解ExtJs ->支持->精华

9 楼 过河卒 2007-10-24  

ajax库越来越多，而且每个js库的实现机制有各有不同，用起来确实不象java库那么轻松。这个是现在最郁闷的事情，给你一个java库你上手，拿到手上有API心里面有底，而JS库心还悬着...

8 楼 cheng022074 2007-10-14  

fangzhouxing 写道

引用

投入项目前先做好功课

建议选择一个小项目来作为练习或评估，许多东西还是需要通过实际做才能体会到。

直接做OA集成项目，开发速度增快45%，原来需要三个合作，现在一个人就可以承担所有的工作，而且开发时间也缩短了

7 楼 fangzhouxing 2007-10-03  

引用

投入项目前先做好功课

建议选择一个小项目来作为练习或评估，许多东西还是需要通过实际做才能体会到。

6 楼 hax 2007-10-01  

xyz20003 写道

hax 写道

BTW，楼上这个抢沙发只能给一星了。

hax老大言重了。在下是看到frank老大在群里发的留言，才过来看一下。估计只比hax老大早点提交了几秒吧？

不是说你，那个抢沙发的已经被隐藏了。

顺便补充一下，如果ext像爱人，那prototype像什么？小情人？还有jquery、mootools、dojo、mochikit……

5 楼 xyz20003 2007-10-01  

hax 写道

楼主的标题有点耸人，难道是翻译来的？我个人认为还没有哪一个ajax库需要像了解爱人一样去了解。。。我自己的项目那也是像了解儿子一样了解。。。

BTW，楼上这个抢沙发只能给一星了。

hax老大言重了。在下是看到frank老大在群里发的留言，才过来看一下。估计只比hax老大早点提交了几秒吧？

爱人这个说法，其实我挺理解的，没女朋友只好把代码当爱人啦。比如在下。。。


虽然不知道ror在前端是如何操作的，但感觉extjs做的前端基本可以脱离后台依赖，只需要提供对应格式的json就可以跑得好好的。在下正在用extjs+java做个东西，数据调用都是使用的json，前台基本上只有html了。

这是一个新闻发布，还处在很初级的阶段，有兴趣的话，过来一起研究一下
http://code.google.com/p/anewssystem/

4 楼 fsword 2007-10-01  

插一句话，ror对前端的封装粒度过细，也就适合封装prototype和scriptaculous这样的工具库，象extjs, jquery-ui（不是jquery）, dojo这样的完整组件库，应该用更大粒度的封装方式，可惜现在没有人做这件事。

3 楼 hax 2007-10-01  

楼主的标题有点耸人，难道是翻译来的？我个人认为还没有哪一个ajax库需要像了解爱人一样去了解。。。我自己的项目那也是像了解儿子一样了解。。。

BTW，楼上这个抢沙发只能给一星了。

2 楼 Hidden 2007-10-01  

好文章，顶...
传说中的沙发？

1 楼 xyz20003 2007-10-01  

就是说，如果只是把extjs包含在自己的项目中，而且这个项目是不是卖给用户做二次开发的工具箱，或组件库，就可以遵守LGPL协议免费使用。你可以不用为ext的发展而捐赠一分钱。