Prototype 与 script.aculo.us终极揭秘
点击看大图基本信息
编辑推荐
深入地覆盖了Prototype和script.aculo.us库的完整细节.
有上百个详细的例子展示服务器端的技术..
覆盖了最佳实践和性能的详尽考虑...
内容简介回到顶部↑
prototype与script.aculo.us库能抹平不同浏览器之间的沟壑，使得一些常见的功能更加容易实现，通过本书你就能迅速掌握这些非常棒的库。深入研究prototype后你将发现，prototype库居然能使javascript变得如此强大，使它看上去更像ruby。在prototype中研究。dom和事件处理、征服ajax，将大大简化你的代码，使一切变得更加简单，而且可移植性更强。当谈及uj的高级特性时，script.aculo.us使得web开发者们的梦想变成现实：创建自动的文本输入用来in-place编辑、提供可定制的拖曳行为、关注用户的需求，这些都只需要简单的代码而已。
本书适合于有一定用javascript进行web开发经验的中级读者，通过对script.aculo.us的学习和研究，能使自己少走很多弯路；本书更加适合于有丰富的javascript开发经验的web高级开发者，他们对script.aculo.us库的需求更迫切些。高级读者还能通过本书分析哲学库的设计原理，然后对其进行改进，使之为自己所用。
本书适合于有一定用javascript进行web开发经验的中级读者，通过对script.aculo.us的学习和研究，能使自己少走很多弯路；本书更加适合于有丰富的javascript开发经验的web高级开发者，他们对script.aculo.us库的需求更迫切些。高级读者还能通过本书分析哲学库的设计原理，然后对其进行改进，使之为自己所用。
作译者回到顶部↑
本书提供作译者介绍
Christophe Porteneuve从事IT研发十多年，早期专注于web开发，从2005年起，涉足Ruby on Rails，从2006年开始与Prototype和script．aculo．us打交道，并致力于它们。他是Prototype官方网站的驱动者之一（http：//plototypejs．org），是一个支持邮件列表的卓越参与者，同时也是Prototype的核心成员。
.. << 查看详细
.. << 查看详细
目录回到顶部↑
序
第1章 引言
1.1 关于时问
1.2 本书的内容及组织结构
1.3 致谢
第ⅰ部分 prototype
第2章 探究prototype
2.1 到底什么是prototype
2.2 如何在项目中使用prototype
2.3 在使用prototype时，javascript看起来会是什么样子
2.4 prototype术语和概念
2.5 那么prototypes究竟是什么
2.6 运行本书中的prototype代码实例
第3章 带有＄的快速帮助
3.1 快捷方式应该简短
3.2 使用＄快速获取巧妙的兀素
3.3 ＄w，因为数组直接量很烦人
3.4 ＄$，使用样式进行查找
3.5 ＄a，集合统一器
3.6 ＄f，表单域专家
第1章 引言
1.1 关于时问
1.2 本书的内容及组织结构
1.3 致谢
第ⅰ部分 prototype
第2章 探究prototype
2.1 到底什么是prototype
2.2 如何在项目中使用prototype
2.3 在使用prototype时，javascript看起来会是什么样子
2.4 prototype术语和概念
2.5 那么prototypes究竟是什么
2.6 运行本书中的prototype代码实例
第3章 带有＄的快速帮助
3.1 快捷方式应该简短
3.2 使用＄快速获取巧妙的兀素
3.3 ＄w，因为数组直接量很烦人
3.4 ＄$，使用样式进行查找
3.5 ＄a，集合统一器
3.6 ＄f，表单域专家
译者序回到顶部↑
很多程序员比较注重服务端开发技术，而对于前台的JavaScript并不是很在意。随着网络技术的飞速发展，JavaScript也在不断地得到改进和深入使用。.
Prototype更使得JavaScript如虎添翼。它提供了一整套“面向对象”的机制，虽然这些都是通过使用原型等技巧来模仿实现的，但是您现在也可以“面向对象”了。而且它还提供了很多功能函数，使一些常用操作更方便了。
Prototype还对很多原生对象、DOM操作、定时器，以及XMLHttpRequest等进行了封装和扩展。此外，它还引入了Enumerable、Template等很多实用的模块和对象。同时大大地提高了代码的简洁度和效率。..
而script.aculo.us为我们提供了美妙的UI感受，以前很多Web程序员常常需要自己写一些效果，纵然效果写得很好，但也花费了不少的时间和精力。如果自己写了很多效果，能否把类似的效果归纳、组织一下，以便以后少写一些重复代码呢？script.aculo.us就为我们做了这些。
自动完成、效果、拖曳，等等，一切都妙不可言。
作者的例子很好也很具有代表性，我们可以自己在网站上借鉴它们。本书源代码下载的网址为：http://books.pragprog.com/titles/cppsu/prototype-and-script-aculo-us。
由于译者水平有限，难免有疏漏和不妥之处，还望广大读者多多指正。
非常感谢博文视点的编辑晓菲的大力帮助。...
陆开一
2008年6月于上海
Prototype更使得JavaScript如虎添翼。它提供了一整套“面向对象”的机制，虽然这些都是通过使用原型等技巧来模仿实现的，但是您现在也可以“面向对象”了。而且它还提供了很多功能函数，使一些常用操作更方便了。
Prototype还对很多原生对象、DOM操作、定时器，以及XMLHttpRequest等进行了封装和扩展。此外，它还引入了Enumerable、Template等很多实用的模块和对象。同时大大地提高了代码的简洁度和效率。..
而script.aculo.us为我们提供了美妙的UI感受，以前很多Web程序员常常需要自己写一些效果，纵然效果写得很好，但也花费了不少的时间和精力。如果自己写了很多效果，能否把类似的效果归纳、组织一下，以便以后少写一些重复代码呢？script.aculo.us就为我们做了这些。
自动完成、效果、拖曳，等等，一切都妙不可言。
作者的例子很好也很具有代表性，我们可以自己在网站上借鉴它们。本书源代码下载的网址为：http://books.pragprog.com/titles/cppsu/prototype-and-script-aculo-us。
由于译者水平有限，难免有疏漏和不妥之处，还望广大读者多多指正。
非常感谢博文视点的编辑晓菲的大力帮助。...
陆开一
2008年6月于上海
序言回到顶部↑
Prototype开始于2005年初，那个时候在多数开发者的印象中“JavaScript”依然是弹出广告、闪烁的文本、[script]标签的拷贝复制。即使一些Web应用程序，比如Gmail以及Google Suggest等，向世界显示了JavaScript（以及新的被叫做“Ajax”的事物）实际上也可以用来改善用户的体验，但是在开发者自己的应用程序中使用这些新的技巧却是令人痛苦和沮丧的。每一种Web浏览器都有自己的一些怪僻，多数现存的代码在设计的时候没有利用JavaScript面向对象的天性或者强大的闭包能力。.
受到来自动态语言，比如Ruby，表达性的灵感，我们着手创建可以期待使用的浏览器编程环境。我们从一小组允许我们和类以及函数共事的工具开始。然后我们从现存的应用程序中萃取常见的Ajax和DOM处理操作。在2005年3月，我们发布了作为Ruby on Rails框架一部分的Prototype 1.0。从那以后，Prototype成长了很多，但是它依然关注于为JavaScript开发者提供最好的开发环境。
至于script.aculo.us，核心团队称之为“Scripty”，它开始是作为Prototype中的一个很小的部分，实现了现在流行的“黄褪技术”。为了使Web应用程序更加地用户友好，视觉愉悦，script.aculo.us很有必要进行改善，因此它很快成长为一个完整的实时的、基于DOM的效果引擎、拖放框架和控件库。它的1.0版本在2005年6月发布。
您应该理解script.aculo.us和很多UI不同，因为它并不是设法把开发者和DOM隔开，而是扩展和改进DOM，这样开发者和设计者可以利用他们现有的知识。
通过和Prototype结合，它被设计为用来构建自己的窗体部件（widget）、控件（control），以及其他很棒的东西，而所用的时间要比配置重量级的、基于窗体部件的框架少得多。
Ruby的设计深深地影响了这两个库，作为Ruby格言（Ruby——A Programmer's Best Friend）的诠释，Prototype 和 script.aculo.us是“Web程序员最好的朋友”。根据得到的反馈，我们不是唯一深有此感的人。
最初版本发行两年半之后，Prototype和script.aculo.us应用在很多最流行的网站上并且为各种创新的应用提供了动力。
它之所以能快速地吸收流行的事物是因为Prototype核心组成员的努力，Prototype和script.aculo.us社团的数百贡献者数千小时的工作；还有本书的作者Christophe。Prototype核心团队成员有Seth Dillingham、Andrew Dupont、Mislav Marohni′c、Justin Palmer、Christophe Porteneuve、Tobie Langel、Scott Raymond以及Dan Webb；
大力感谢他们和你们！
Sam Stephenson（Creator of Prototype）
2007年10月15日
Thomas Fuchs（Creator of script.aculo.us）
2007年10月15日
推荐序
2005年对于Web开发来说是一个伟大的年份。在这一年中，有两项技术异军突起，一项是Ajax，另一项是Ruby on Rails。这两项技术的出现改变了Web开发的面貌，甚至打乱了JavaEE前进的步伐。多年以来，JavaEE设计者们为自己所设计的无所不包的复杂架构而陶醉，新的buzz word层出不穷，一出来就会得到广泛的关注，相关的图书也会热卖。辉煌的JavaEE版图中居然还有完全被忽略的死角，这是JavaEE设计者们始料不及的。事实上他们在JavaEE的架构中从来就没有考虑过浏览器端的处理能力，浏览器对于JavaEE来说是完全无智能的瘦客户端。他们这样设计情有可原，因为他们只能把设计局限在Java能够控制的区域内，在Java Applet彻底失败之后，Java能够控制的区域退守到了服务器端。毫无疑问，JavaEE取得了巨大的成功，但是这种完全基于服务器端的解决方案很难向用户提供优秀的交互体验，同时也很难实现最佳的可伸缩性（Scalability）。..
Ajax是用户和市场的选择，这个由群众创造出来的buzz word时常响在JavaEE设计者的耳边，令他们非常烦躁。甚至有人喊出了“JavaEE without Ajax”的口号，和2004年Rod Johnson所提出的“J2EE without EJB”相对应。但是仔细考察这个“without Ajax”，我们却发现它和“without EJB”说的并不是一个意思。“without EJB”的意思就是不使用EJB，而“without Ajax”的意思却不是不使用Ajax，而是设法将Ajax隐藏掉，使得普通的JavaEE开发者不需要学习Ajax。在这个口号的发明者所设计的JSF框架中，内嵌了一个Ajax组件库ExtJS，看来他们还是需要Ajax的帮助的。所谓的“JavaEE without Ajax”其实是一个伪命题，只是用来吸引眼球的噱头，主要的目的是为了迎合那些讨厌Ajax、对于浏览器端脚本编程没有兴趣的JavaEE开发者。其实无论开发Web应用，还是开发B/S结构的企业应用，交互体验都是非常重要的。在交互体验越来越受到重视的今天，想要把Ajax排除在外，可以说是一件不可能的任务。
尽管Ajax开发确实很重要，但无须讳言的是Ajax开发，特别是DHTML开发至今仍然是一件很复杂的工作，必须具备专业的技能。除了高超的开发技能之外，还需要开发者对于Web可用性和交互设计具有足够的理解。这超出了Web页面设计师和制作人员的能力范围；而对于服务器端开发者来说，这些显然也不是他们的特长（他们的特长是处理业务逻辑和与数据库打交道，而不是界面开发和交互设计）。在Web页面设计师和服务器端开发者之间出现了巨大的断层，这使得高水平的Ajax开发者一下子变得炙手可热。
JavaEE设计者们简化Ajax开发的努力是可以理解的。但是我们需要讨论清楚一个问题：究竟怎样做才能真正简化Ajax开发？
在我看来，JavaEE社区简化Ajax开发的努力都不是很成功。将ExtJS嵌入到JSF框架中，确实可以实现一些简单的交互需求，但是这种做法其实阉割掉了Ajax的主要能力——直接在浏览器端处理用户的事件。JSF的事件模型是完全位于服务器端的，界面的任何改变都需要发送事件到服务器端做处理。即使引入了ExtJS，也不可能改变这一点。在Struts2/WebWork和jMaki中通过使用taglib集成Ajax组件库的做法也会令人感觉笨拙而不自然。之所以集成的效果不理想，是因为传统的JavaEE框架和Ajax组件库的核心架构设计都没有考虑到对方的需求，它们在架构设计上存在着内在的冲突，拉郎配的结果是可想而知的。这些JavaEE表现层框架集成Ajax组件库，是希望将Ajax组件库改造为JavaEE世界的顺民，服从JavaEE框架的架构约束，但是这样做不可避免地会削弱Ajax组件库的能力。要简化Ajax开发并且充分用好Ajax技术，仅仅使用taglib来对Ajax组件库做封装是不够的，服务器端的架构也必须加以改造，甚至需要设计出一套全新的架构，这是传统的JavaEE表现层框架无法做到的。Google的GWT同时具有浏览器端和服务器端，似乎是一个很好的选择，但是GWT主要是为实现一类One Page的Ajax应用而设计的，它模仿的是桌面应用的交互模型，而绝大多数的Web应用是不可能采用这种交互模型的。DWR也是一个跨浏览器端和服务器端的框架，但是DWR的RPC风格的API是我所不喜欢的。RPC架构和REST架构在可伸缩性方面的差距是巨大的，Ajax应用的最佳架构是REST而不是RPC，同时REST在简化编程模型方面的效果也要比RPC更好。
受到来自动态语言，比如Ruby，表达性的灵感，我们着手创建可以期待使用的浏览器编程环境。我们从一小组允许我们和类以及函数共事的工具开始。然后我们从现存的应用程序中萃取常见的Ajax和DOM处理操作。在2005年3月，我们发布了作为Ruby on Rails框架一部分的Prototype 1.0。从那以后，Prototype成长了很多，但是它依然关注于为JavaScript开发者提供最好的开发环境。
至于script.aculo.us，核心团队称之为“Scripty”，它开始是作为Prototype中的一个很小的部分，实现了现在流行的“黄褪技术”。为了使Web应用程序更加地用户友好，视觉愉悦，script.aculo.us很有必要进行改善，因此它很快成长为一个完整的实时的、基于DOM的效果引擎、拖放框架和控件库。它的1.0版本在2005年6月发布。
您应该理解script.aculo.us和很多UI不同，因为它并不是设法把开发者和DOM隔开，而是扩展和改进DOM，这样开发者和设计者可以利用他们现有的知识。
通过和Prototype结合，它被设计为用来构建自己的窗体部件（widget）、控件（control），以及其他很棒的东西，而所用的时间要比配置重量级的、基于窗体部件的框架少得多。
Ruby的设计深深地影响了这两个库，作为Ruby格言（Ruby——A Programmer's Best Friend）的诠释，Prototype 和 script.aculo.us是“Web程序员最好的朋友”。根据得到的反馈，我们不是唯一深有此感的人。
最初版本发行两年半之后，Prototype和script.aculo.us应用在很多最流行的网站上并且为各种创新的应用提供了动力。
它之所以能快速地吸收流行的事物是因为Prototype核心组成员的努力，Prototype和script.aculo.us社团的数百贡献者数千小时的工作；还有本书的作者Christophe。Prototype核心团队成员有Seth Dillingham、Andrew Dupont、Mislav Marohni′c、Justin Palmer、Christophe Porteneuve、Tobie Langel、Scott Raymond以及Dan Webb；
大力感谢他们和你们！
Sam Stephenson（Creator of Prototype）
2007年10月15日
Thomas Fuchs（Creator of script.aculo.us）
2007年10月15日
推荐序
2005年对于Web开发来说是一个伟大的年份。在这一年中，有两项技术异军突起，一项是Ajax，另一项是Ruby on Rails。这两项技术的出现改变了Web开发的面貌，甚至打乱了JavaEE前进的步伐。多年以来，JavaEE设计者们为自己所设计的无所不包的复杂架构而陶醉，新的buzz word层出不穷，一出来就会得到广泛的关注，相关的图书也会热卖。辉煌的JavaEE版图中居然还有完全被忽略的死角，这是JavaEE设计者们始料不及的。事实上他们在JavaEE的架构中从来就没有考虑过浏览器端的处理能力，浏览器对于JavaEE来说是完全无智能的瘦客户端。他们这样设计情有可原，因为他们只能把设计局限在Java能够控制的区域内，在Java Applet彻底失败之后，Java能够控制的区域退守到了服务器端。毫无疑问，JavaEE取得了巨大的成功，但是这种完全基于服务器端的解决方案很难向用户提供优秀的交互体验，同时也很难实现最佳的可伸缩性（Scalability）。..
Ajax是用户和市场的选择，这个由群众创造出来的buzz word时常响在JavaEE设计者的耳边，令他们非常烦躁。甚至有人喊出了“JavaEE without Ajax”的口号，和2004年Rod Johnson所提出的“J2EE without EJB”相对应。但是仔细考察这个“without Ajax”，我们却发现它和“without EJB”说的并不是一个意思。“without EJB”的意思就是不使用EJB，而“without Ajax”的意思却不是不使用Ajax，而是设法将Ajax隐藏掉，使得普通的JavaEE开发者不需要学习Ajax。在这个口号的发明者所设计的JSF框架中，内嵌了一个Ajax组件库ExtJS，看来他们还是需要Ajax的帮助的。所谓的“JavaEE without Ajax”其实是一个伪命题，只是用来吸引眼球的噱头，主要的目的是为了迎合那些讨厌Ajax、对于浏览器端脚本编程没有兴趣的JavaEE开发者。其实无论开发Web应用，还是开发B/S结构的企业应用，交互体验都是非常重要的。在交互体验越来越受到重视的今天，想要把Ajax排除在外，可以说是一件不可能的任务。
尽管Ajax开发确实很重要，但无须讳言的是Ajax开发，特别是DHTML开发至今仍然是一件很复杂的工作，必须具备专业的技能。除了高超的开发技能之外，还需要开发者对于Web可用性和交互设计具有足够的理解。这超出了Web页面设计师和制作人员的能力范围；而对于服务器端开发者来说，这些显然也不是他们的特长（他们的特长是处理业务逻辑和与数据库打交道，而不是界面开发和交互设计）。在Web页面设计师和服务器端开发者之间出现了巨大的断层，这使得高水平的Ajax开发者一下子变得炙手可热。
JavaEE设计者们简化Ajax开发的努力是可以理解的。但是我们需要讨论清楚一个问题：究竟怎样做才能真正简化Ajax开发？
在我看来，JavaEE社区简化Ajax开发的努力都不是很成功。将ExtJS嵌入到JSF框架中，确实可以实现一些简单的交互需求，但是这种做法其实阉割掉了Ajax的主要能力——直接在浏览器端处理用户的事件。JSF的事件模型是完全位于服务器端的，界面的任何改变都需要发送事件到服务器端做处理。即使引入了ExtJS，也不可能改变这一点。在Struts2/WebWork和jMaki中通过使用taglib集成Ajax组件库的做法也会令人感觉笨拙而不自然。之所以集成的效果不理想，是因为传统的JavaEE框架和Ajax组件库的核心架构设计都没有考虑到对方的需求，它们在架构设计上存在着内在的冲突，拉郎配的结果是可想而知的。这些JavaEE表现层框架集成Ajax组件库，是希望将Ajax组件库改造为JavaEE世界的顺民，服从JavaEE框架的架构约束，但是这样做不可避免地会削弱Ajax组件库的能力。要简化Ajax开发并且充分用好Ajax技术，仅仅使用taglib来对Ajax组件库做封装是不够的，服务器端的架构也必须加以改造，甚至需要设计出一套全新的架构，这是传统的JavaEE表现层框架无法做到的。Google的GWT同时具有浏览器端和服务器端，似乎是一个很好的选择，但是GWT主要是为实现一类One Page的Ajax应用而设计的，它模仿的是桌面应用的交互模型，而绝大多数的Web应用是不可能采用这种交互模型的。DWR也是一个跨浏览器端和服务器端的框架，但是DWR的RPC风格的API是我所不喜欢的。RPC架构和REST架构在可伸缩性方面的差距是巨大的，Ajax应用的最佳架构是REST而不是RPC，同时REST在简化编程模型方面的效果也要比RPC更好。
媒体评论回到顶部↑
What readers are saying about Prototype and script.aculo.us
我一直在工作中使用Prototype和script.aculo.us，但是通过本书我学到了很多。我常常回来翻阅它以查找一些在其他地方找不到的内容。这是一本由很有经验的老师编写的对编程人员很有帮助的书，它会对所有希望能够轻易地为他们的应用添加JavaScript特性的读者大有帮助。
Stephane Akkaoui .
Ruby on Rails开发者，Feedback 2.0
如果您（或您的小组）打算学习JavaScript框架，这本书将是一位指引您毫不费力地一步步通往Prototype 和script.aculo.us的向导。它以最简洁的风格编写从基础的到高级的代码。您会惊讶地发现JavaScript可以做得如此完美。
Arnaud Berthomier
Web开发者，Weborama
这本书是所有的Prototype和script.aculo.us开发者都应该拥有的。它不只是一本参考书；您会找到您想知道的关于这两个框架的所有东西，您会学到很好的JavaScript习惯。我已经学到了很多script.aculo.us技巧，并且掌握了很多Prototype方法，它们使得我的代码在提高功效的同时也更加简洁、更具可读性。感谢这本书！..
Sebastien Gruhier
Xilinus创始人和CTO
厌倦了页面加载一次又一次的等待了么？如果您像我一样，正在寻找一个智能的、优雅的方法来为您的应用注入Ajax的话。那好，您会在这本书中发现了解Prototype和 script.aculo.us所需的一切。这本书在助您掌握最佳实践的同时也不失趣味性！
Amir Jaballah
Fastconnect技术组长
我们为所有的Web项目使用Prototype和Script.aculo.us。当我们培训其他开发者的时候，总会提到两个问题：从哪里可以得到更多关于库的信息？从哪里可以学习现代的、函数风格的JavaScript编程？
本书同时回答了这两个问题。
Christophe演示了这些库以及惯用的JavaScript风格的力与美。他不流于表面，他的介绍显示了高级的JavaScript用法，甚至比有些整本介绍JavaScript的书还要深入。虽然已使用了多年的Prototype和script.aculo.us，我还是从每一章中学到了新的东西。感谢Christophe!
Stuart Halloway ...
Relevance, Inc.CEO
www.thinkrelevance.com
我一直在工作中使用Prototype和script.aculo.us，但是通过本书我学到了很多。我常常回来翻阅它以查找一些在其他地方找不到的内容。这是一本由很有经验的老师编写的对编程人员很有帮助的书，它会对所有希望能够轻易地为他们的应用添加JavaScript特性的读者大有帮助。
Stephane Akkaoui .
Ruby on Rails开发者，Feedback 2.0
如果您（或您的小组）打算学习JavaScript框架，这本书将是一位指引您毫不费力地一步步通往Prototype 和script.aculo.us的向导。它以最简洁的风格编写从基础的到高级的代码。您会惊讶地发现JavaScript可以做得如此完美。
Arnaud Berthomier
Web开发者，Weborama
这本书是所有的Prototype和script.aculo.us开发者都应该拥有的。它不只是一本参考书；您会找到您想知道的关于这两个框架的所有东西，您会学到很好的JavaScript习惯。我已经学到了很多script.aculo.us技巧，并且掌握了很多Prototype方法，它们使得我的代码在提高功效的同时也更加简洁、更具可读性。感谢这本书！..
Sebastien Gruhier
Xilinus创始人和CTO
厌倦了页面加载一次又一次的等待了么？如果您像我一样，正在寻找一个智能的、优雅的方法来为您的应用注入Ajax的话。那好，您会在这本书中发现了解Prototype和 script.aculo.us所需的一切。这本书在助您掌握最佳实践的同时也不失趣味性！
Amir Jaballah
Fastconnect技术组长
我们为所有的Web项目使用Prototype和Script.aculo.us。当我们培训其他开发者的时候，总会提到两个问题：从哪里可以得到更多关于库的信息？从哪里可以学习现代的、函数风格的JavaScript编程？
本书同时回答了这两个问题。
Christophe演示了这些库以及惯用的JavaScript风格的力与美。他不流于表面，他的介绍显示了高级的JavaScript用法，甚至比有些整本介绍JavaScript的书还要深入。虽然已使用了多年的Prototype和script.aculo.us，我还是从每一章中学到了新的东西。感谢Christophe!
Stuart Halloway ...
Relevance, Inc.CEO
www.thinkrelevance.com
书摘回到顶部↑
第1章 引言
Prototype是一个奇妙的JavaScript库，它的目的是使用动态Web应用的开发更加容易。它的亲密伙伴script.aculo.us提供了很多基于用户界面的令人惊讶的特性，比如拖放、自动完成、鼠标驱动的元素排序、奇妙的视觉效果，以及In-Place编辑。
它们之间的亲密关系是因为它们都是源自Ruby on Rails世纪，是Rails的“副产品”。……
Prototype是一个奇妙的JavaScript库，它的目的是使用动态Web应用的开发更加容易。它的亲密伙伴script.aculo.us提供了很多基于用户界面的令人惊讶的特性，比如拖放、自动完成、鼠标驱动的元素排序、奇妙的视觉效果，以及In-Place编辑。
它们之间的亲密关系是因为它们都是源自Ruby on Rails世纪，是Rails的“副产品”。……
加载中...
