[b]投入项目前先做好功课 [/b]
[b][color=darkred]EXT无疑是最近前端开发最受关注的话题。在近一年的YUI-Ext 0.30/ExtJS 1.X开发之后，上周五ExtJS又推出它的升级版本2.0，而更多的开发者也参与到前端开发这一领域来。 在Web2.0/Enterprise2.0声势、日益强调用户体验的情况下，选择EXT是否明智？这些都需要开发者慎重决策。[/color][/b]
[b]项目参与EXT切忌盲目 [/b]
据资深IT分析人士表示，目前界业内的Ajax热浪，一方面是由于2005年以来的Google一线产品使人带来极大的用户体验，另一方面来自对旧事物新改造的关注。
第一只“出海”的YUI-Ext只是作者Jack打算对基于BSD协议的Yahoo!UI库进行自定义的扩展，但后来一度风头盖过其父辈YUI，足以说明大家对它的热情，很多人把它投入项目人并不十分了解它。分析人士打了一比喻：就好比尚未谋面， 并不了解一个人的家庭、教育、品行等背景，只因为他有一副精致漂亮的外观，就对其陷入了疯狂的倾慕之中。因此分析人士建议，在投入项目前，要认真仔细地了解EXT的内在原理和与其他Ajax库不同地方。
Ext的UI组件模型和开发理念脱胎、成型于Yahoo组件库YUI和Java平台上Swing两者，并为开发者屏蔽了大量跨浏览器方面的处理。相对来说，EXT要比开发者直接针对DOM、W3C对象模型开发UI组件轻松。
[b]Ajax库各有不同 [/b]
目前业界中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库，允许方便地“可视化编程”。
[b]决定实施之前多作比较 [/b]
实际上，目前关于是否应该封装EXT“控件”存在着两种完全不同的意见。已有实践开发EXT经验的朋友甚至原作者Jack都表示，手工JS编码更适合EXT开发，这样各组件的耦合颗粒度更细，项目整体的灵活度机会高。而另一派的观点则认为，在Java/.Net的大背景下，多数开发者希望利用IDE或类似VB的GUI“画出”控件这样强大的支持来解决表示层的方案，以提供工作效率；另一方面，大量JavaScript投入项目产生，开发者会因JavaScript另外一本质－－－基于函数式编程（LISP但是C语法系）的困惑而对项目设计而大打折扣，我们没有道理离开熟悉的领域到陌生的地方去冒险。
由于绝大多数EXT产品的都在实践和测试之中，因此，国内的开发者确实需要慎重思考，认真研读相关JS库的文档和资料，并将其与自己熟悉的JS库比较，确实了解其风险与客户需求再作决定。
另外对于打算购买商业许可的用户，开发者还需要注意不同的商业的价格是不一样的。每种许可一般分为仅源码、源码＋技术支持和1.x的升级。而企业级的EXT许可证的门槛更高，大多在两万元人民币以上。
[b]许可解读 [/b]
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项目）”。
[b][color=darkred]EXT无疑是最近前端开发最受关注的话题。在近一年的YUI-Ext 0.30/ExtJS 1.X开发之后，上周五ExtJS又推出它的升级版本2.0，而更多的开发者也参与到前端开发这一领域来。 在Web2.0/Enterprise2.0声势、日益强调用户体验的情况下，选择EXT是否明智？这些都需要开发者慎重决策。[/color][/b]
[b]项目参与EXT切忌盲目 [/b]
据资深IT分析人士表示，目前界业内的Ajax热浪，一方面是由于2005年以来的Google一线产品使人带来极大的用户体验，另一方面来自对旧事物新改造的关注。
第一只“出海”的YUI-Ext只是作者Jack打算对基于BSD协议的Yahoo!UI库进行自定义的扩展，但后来一度风头盖过其父辈YUI，足以说明大家对它的热情，很多人把它投入项目人并不十分了解它。分析人士打了一比喻：就好比尚未谋面， 并不了解一个人的家庭、教育、品行等背景，只因为他有一副精致漂亮的外观，就对其陷入了疯狂的倾慕之中。因此分析人士建议，在投入项目前，要认真仔细地了解EXT的内在原理和与其他Ajax库不同地方。
Ext的UI组件模型和开发理念脱胎、成型于Yahoo组件库YUI和Java平台上Swing两者，并为开发者屏蔽了大量跨浏览器方面的处理。相对来说，EXT要比开发者直接针对DOM、W3C对象模型开发UI组件轻松。
[b]Ajax库各有不同 [/b]
目前业界中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库，允许方便地“可视化编程”。
[b]决定实施之前多作比较 [/b]
实际上，目前关于是否应该封装EXT“控件”存在着两种完全不同的意见。已有实践开发EXT经验的朋友甚至原作者Jack都表示，手工JS编码更适合EXT开发，这样各组件的耦合颗粒度更细，项目整体的灵活度机会高。而另一派的观点则认为，在Java/.Net的大背景下，多数开发者希望利用IDE或类似VB的GUI“画出”控件这样强大的支持来解决表示层的方案，以提供工作效率；另一方面，大量JavaScript投入项目产生，开发者会因JavaScript另外一本质－－－基于函数式编程（LISP但是C语法系）的困惑而对项目设计而大打折扣，我们没有道理离开熟悉的领域到陌生的地方去冒险。
由于绝大多数EXT产品的都在实践和测试之中，因此，国内的开发者确实需要慎重思考，认真研读相关JS库的文档和资料，并将其与自己熟悉的JS库比较，确实了解其风险与客户需求再作决定。
另外对于打算购买商业许可的用户，开发者还需要注意不同的商业的价格是不一样的。每种许可一般分为仅源码、源码＋技术支持和1.x的升级。而企业级的EXT许可证的门槛更高，大多在两万元人民币以上。
[b]许可解读 [/b]
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项目）”。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
