[资料] 参考资料

littcai 2008-12-15

教程类

Mootools 1.2系列教程
http://ooboy.net/blog/article/605.aspx

Mootools 1.2系列教程(英文)
http://www.consideropen.com/blog/2008/08/30-days-of-mootools-12-tutorials-day-1-intro-to-the-library/

 

 

源码分析类 

MooTools源码分析
http://blog.csdn.net/lenoval/category/451244.aspx?PageNumber=5



Mootools 示例
http://sixrevisions.com/javascript/mootools_tutorials_and_example/

框架比较类

老外的一篇比较Mootools和其他框架区别的文章
http://mootorial.com/wiki/mootorial/00a-mootoolsvsothers

 

tiyi 2008-12-19
我可以加入吗
tiyi 2009-01-06
我还是比较喜欢mootools,之前用过prototype,算是入门到oo js的。
而后开始跟进yui 然后是yui-ext(现在是ext) 一路下来发现还是
mootools最简单。最能满足页面控制的需要。

我一直认为js界面组件不是大势所趋 -- 除非 google可以把他的浏览器作到
像解析本地代码一样解释js。虽然现在ext应用很多。但是还是有场景限制。
因为国内有些客户还在使用老牛机器,一上ext就明显感觉浏览器撑不住。

mootools胜在够简洁,设计的理念也很简单。基本上一本mht的手册
就能应付。
window.addEvent('domready',function(){}) ;
虽然较之 Ext.onReady 冗余一些。。使用久了倒也习惯了。

只是$F 这个函数没有,使得prototype习惯下来的人,有点不适应,但是还是可以自定义。。

littcai 2009-01-06
同意。本质上浏览器从字面上来说就是用来“浏览”的。因为用户群的要求提升及Web2.0的出现,在友好性及交互上需要做更多的处理,才使界面组件有了提升。进而开始出现各种各样的小组件及完成的WebUI框架。
浏览器本身的HTML+JS+CSS的语法限制外加不同浏览器版本的兼容性使得做好界面小组件非常难,大家才倾向于使用完整的WebUI框架。同时引入了复杂性及完全不同的编程理念。最典型的就是在使用EXT的时候HTML少了,取而代之的是一堆的JS脚本。以往的美工再没用武之地,最后写出来的就是一个个大同小异的界面。

我个人的理解:如果是想做富客户端的,还不如用FLEX等技术,EXT最多也只能用来写写后台程序。而我们在平时用的最多的,在项目间无影响的还是“界面小组件”(Widgets),及界面本身的主体还是建立在HTML+CSS基础上的,只在需要丰富呈现及丰富交互的时候才使用Widgets。如需要弹出框的时候加载一个Windows组件,在需要超链提示的时候使用一个Tip组件。
littcai 2009-01-06
我之前一直使用prototype,但基本也仅限于那个$符号。后来发现了mootools,马上被其的精巧吸引了,在mootools的架构上写小组件十分得心应手。很多功能只需一个继承或者一个方法调用就实现了。
lenoval 2009-02-25
我也是,
chumpklutz 2009-02-26
LOVE MOOTOOLS
karoel 2009-03-06
学习下呵呵
Global site tag (gtag.js) - Google Analytics