Yahoo!用户界面博客（YUIBlog）

解剖3.5.0 DataTable中，第1部分

2012年5月1日，12:43上午由卢克·史密斯| 开发 | 没有评论

DataTable has been one of YUI's most heavily used and relied upon widgets for years. In 3.5.0, DataTable got a major overhaul, resulting in some small changes to the API and some big changes to the infrastructure.

In this two part article, we'll talk about these changes, what led up to the decision to revisit the infrastructure rather than focus on features, break down some of the new and experimental concepts being explored, and finish up with a look at the plan for the future of DataTable as we see it today.

So without further ado, let's address the obvious question:

Why Refactor?

The short answer is "to make DataTable easier to use and customize". The 3.4.1 infrastructure was based on a "core" Widget model, with all additional features left to plugins or subclasses. The data was held in a Y.Recordset instance and the column configuration in a Y.Columnset instance. The Widget was responsible for creating the entire table markup. That seemed like a reasonable architecture, but there were a few issues with this:

1. DataTables are defined by their features, which means there could be a lot of plug()ing to get the DataTable that fits your application. This made working with DataTable too complicated and verbose.
2. The contract of the Plugin API hindered DataTable's multiple features from interacting properly. In fact, certain DataTable features in 3.4.1 had already started breaking this contract.
3. DataTable was hard coded to use Y.Record, Y.Recordset, Y.Column, and Y.Columnset. This coupling limited the ability to customize DataTable or integrate it with other components in your application.
4. The rendering algorithm was flexible, but its hooks for customization were fixed. There was an opportunity to make rendering more customizable (and a whole lot faster) without requiring implementers to do major surgery on their instances.

The new architecture aims to address these and other issues uncovered during its production life prior to 3.5.0, and take advantage of the App Framework components that weren't around when DataTable was initially created in 3.3.0.

DataTable is incredibly important to a lot of people, and it's important to us that it not only be built right, but also that it be as easy to use as possible. These changes aim to move DataTable in the right direction.

Big Changes

The major changes from 3.4.1 to 3.5.0 are mostly under the hood, and with any luck, migrating to 3.5.0 DataTable should be painless.

Most of the outward changes to the API make it much easier to add and use DataTable features. Compare a 3.4.1 sortable DataTable to its 3.5.0 equivalent:

一个名称是什么？

你会注意到的第一件事是，截至3.5.0，创建实例Y.DataTable而比Y.DataTable.Base 。 基类仍是左右，但现在它的主要作用是作为一个超类扩展（我们将在下一篇文章中谈论更多有关）。

Y.DataTable是现在的主类和类支持的DataTable，如命名空间Y.DataTable.Base ， Y.DataTable.Sortable ， Y.DataTable.BodyView 。 值得注意的例外是Y.Plugin.DataTableDataSource ，尚未被迁移到新的世界秩序（预期在3.6.0）。

你会看到在下一篇文章中，当我们谈一些有关DataTable的新概念。

作为一类扩展的特点

3.5.0架构标志着一个转变 ，从DataTable中的插件模型。 相反，我们把类的扩展功能，并使用的强大Y.Base.mix()方法，以增加这些功能的DataTable类，创建一种特设多重继承模式。

这种方法的主要优点是：

1. 您的DataTable和其所有功能的API是在一个地方，你Y.DataTable实例。
2. 行，而不是明确地建立基地的DataTable，只需在您的功能模块use() ，包括增加了对这些功能的支持的Y.DataTable类。

但如果你有几个页面上的数据表，你不希望所有这些排序或滚动等吗？

保持泄漏DataTable实例之间的功能，每个功能包括行为触发，这是负责该特定实例的激活功能。 一个功能可能分配表的属性，如“滚动”，或“宽度”，如列配置。 它甚至可能有多个触发器，如datatable-sort “排序”表属性或“排序”列配置属性。

没有更多的耦合

3.5.0， Y.Columnset和Y.Column都走了，你不仅限于数据存储Y.Record和Y.Recordset 。

现在存储为一个简单的对象数组，就像你通过DataTable的columns属性列定义。

这种变化的原因是，许多功能是具体列，列定义一个自然的地方，它们的配置。 但列类不应该包括功能相关的属性，除非该功能要求。 然而，作为插件实现的功能不应该直接修改类。 那么，怎样才能列定义包括sortable: true ，如果不列类有一个sortable属性，插件不能添加？ 有没有一个很好的答案，所以我们（可惜）增加了功能属性的基列类，允许他们做什么，除非插件添加。 与许多悬而未决的DataTable要在列定义配置的功能，我们决定删除在3.5.0列类包装，让需要的任何属性定义的列。 陪审团仍然是对这种变化，所以我们在您的反馈感兴趣。

Recordset和记录数据上的东西，在技术上做工精细，但在3.4.0 Y.Model和Y.ModelList的到来，现在有一个巨大的机会，分享类是在其他地方可能被用来应用。 然而，这意味着的DataTable将需要从它的数据存储类中分离出来，因为共同使用的情况下为应用程序框架组件是专门封装业务逻辑的属性和API创建它们的子类。

因此，在3.5.0，而不是被绑定到Y.Record ，数据记录存储在模型的子类的实例。 DataTable将默认情况下，为您创建一个模型的子类，定制的数据，但你现在可以选择指定的类，通 ​​过设置DataTable的recordType属性的使用。 同样，您可以提供您的表的data在ModelList或样ModelList对象。

现在，如果您共享您的ModelList或您的应用程序的各个部分之间的模型，其中的任何修改将自动更新该表。

定制的渲染

3.5.0在渲染算法是完全重写，现在是明显更快，超过其3.4.1对应配置。 迁移指南和用户指南进入各单元格的格式选项的细节，但一个重要的变化是值得在这里，整个算法可以用一个简单的配置变化所取代。

在保持配置数据存储类的举动，现在的DataTable代表渲染算法Y.View类。 在3.5.0中基本的，无特色的DataTable有：属性headerView ， bodyView ， footerView 。 默认情况下， footerView没有设置，但headerView设置到Y.DataTable.HeaderView ， bodyView设置到Y.DataTable.BodyView 。

当一个DataTable实例render()版，唯一的DOM内容的Widget本身是一种负责任<table>及其直接子。 渲染的页眉内容，页脚内容，数据行留下任何视图类提供给各自的属性。

默认视图在3.5.0提供足够的列配置选项处理大多数用例，但是，如果你有你的表呈现的特殊要求，或你想超优化您的具体实施，您可以提供您自己的视图类的属性如上所述，DataTable将使用它们。

更多的惊喜

下一篇文章将进入DataTable的建筑技术，实验模式，什么在下一个版本中的有关细节。

与此同时，务必让我们知道在yuilibrary.com论坛上， Twitter的，和＃YUI freenode的IRC频道上，事情怎么会在DataTable中的应用程序，您有什么特点，你最期待的。

找到的谈话： bloglines technorati

共享和扩展： 书签del.icio.us Digg它！ | reddit！

锐：营业时间周四5月3日

卢克·史密斯，2012年4月30日4:05下午| 开发 | 评论

摆弄周围使用DataTable

我感觉就像所有其他的营业时间有关DataTable是，但我想这并非事实。 因此，让我们谈论的DataTable！

特别是，我想谈谈两件事情：

1. 列配置和细胞格式化的提示和技巧
2. 什么是速度快，是缓慢的，以及如何最大限度地发挥DT性能

这将是直播编码的的很多jsfiddle ，但我会尝试的东西有几个例子prepped。 如果有一个具体的例子，你想看到的，格式化你想回答的问题，或一般任何其他DT的问题或反馈，请带上它。

录音

录音是在YUILibrary YouTube频道 ，虽然质量不出来很好。

提到

• 飞锤代理ModelList
• 从数据的变化更精确的DOM更新
• 更简单的渲染逻辑与自定义bodyView

找到的谈话： bloglines technorati

共享和扩展： 书签del.icio.us Digg它！ | reddit！

概括代码通过功能性编程

2012年4月30日9:13 | 开发 | 评论由约翰Lindal上午

抽象是一个热门词语，但很多人说， 抽象的，当他们真正的意思概括。这两个概念有很大的不同。 事实上，它们适用于编码过程的两端。

已经写了很多关于如何抽象，简化软件建设， 在大型编程时的工作。不幸的是，抽象泄漏，证明Joel Spolsky的 杰夫阿特伍德 。 这是不足为奇的，抽象的定义：考虑到一些独立的协会，属性，或混凝土伴奏的过程中。 换句话说，抽象忽略的细节，这总是回来咬我们。

推广，另一方面，是集中在一个特定的问题，即在小编程时有用。概括的目标是使一个问题可用较大的类的相关问题的解决方案。 这是最终的代码重用：建设和使用它一遍又一遍。 只要做正确的泛化，有没有危险，失败，虽然总有不把它远远不够的可能性。

有许多方法来概括代码。 本文将重点建设高阶功能，尤其是实力的功能性语言。 让我们先从两个明显的例子： map和reduce适用于在一个集合的每个元素的功能。 产生一个新的集合或价值，分别从现有的集合，这些概括的概念。

它应该是可能的，概括的map并进一步reduce ，工作，即对森林，树木的集合，而不是只有一个项目的集合。 然而，问题是代码递归必须知道如何树木存储。 是一棵树简单的嵌套数组，例如， [1, [2, 3], 4]或者是每个节点的子节点的数组必须提取的对象呢？ 为reduce ，可以通过在函数提取的孩子：

功能reduceForest（根，初始，运作，儿童）
 {
	返回Y.Array.reduce（根，初始功能（价值，根）
	 {
		返回reduceForest（儿童（根），操作（价值，根），经营，子女）;
	 }）;
 }

然而， map ，它是更为复杂，因为也有结果应该看起来像什么的问题。 一个嵌套数组可以被映射到另一个嵌套数组，可以映射到另一个对象树和对象树，但在同一时间支持将使相当复杂的代码。 知道何时停止概括是知道何时继续一样重要！

我们可以分出不同的方向，然而，因为有许多类型的集合，但上面的代码需要将存储阵列中的儿童。 我们需要概括迭代的概念。

这YUI的oop.js提供，私有函数dispatch 。 这里是稍微调整的版本所使用的画廊funcprog ：

调度功能（行动，O）
 {
	 VAR ARGS = Y.Array（参数1，TRUE）;
	开关（Y.Array.test（O））
	 {
		例1：
			返回Y.Array [动作]申请（空里，args）;
		例2：
			参数[0] = Y.Array（O，0，TRUE）;
			返回Y.Array [动作]申请（空里，args）;
		默认值：
			 （Ø&&Ø[动作] &&Ø！==Ÿ）
			 {
				 args.shift（）;
				返回的问题o [动作]申请（O，则args）;
			 }
			其他
			 {
				返回Y.Object [动作]申请（空里，args）;
			 }
	 }
 }

这是奇妙的一般。 任何行动：地图，减少，过滤器，等阵列路由到Y.Array 。 实施行动的对象是直接调用，允许个人类优化个人行为。 所有其他对象操作在通用，版本Y.Object （提供画廊对象的演员 ）。 夏普的读者会注意到，迭代对象成员的顺序是不确定的，但是这并不重要map ， reduce与交换的运营商， filter等（使用Y.some您自己的风险，但。）

选择对象，实施行动的自定义版本导致又一概括： 画廊可迭代的额外的 。 这个mixin的实现提供任何对象的所有操作iterator方法。 唯一的要求是， iterator next公开和atEnd iterator必须返回一个对象。 尤其是这是链表的效率，索引查找是O（N），但它也可以简化其他类别，例如， Y.NodeList ，因为一个没有明确落实图，减少，过滤器等

当然，概括不具备成为这个复杂的。 当我在写画廊排序的演员 ，我先建此功能：

 Y.Sort.compareKeyAsString =（A，B键，）
 {
    回报compareAsString（[关键]，B [关键]）;
 };

但后来我意识到，我会写一个单独的compareKeyAsNumber ，所以不是我推广到：

 Y.Sort.compareKeyAs =功能（F，A，B键，）
 {
    返回f（[关键]，B [关键]）;
 };

由于sort需要一个功能，只需要(a,b)必须使用Y.bind 修复前两个参数 ：

 排序（Y.bind（Y.Sort.compareAsKey，空，Y.Sort.compareAsString，关键）） 

到目前为止，我们只考虑功能操作功能。 你也可以建立功能，返回功能。 一个简单的例子是一个反向排序的功能：

 Y.Sort.flip =功能（F）
 {
    返回功能（A，B）
     {
        返回f（B，A）;
     };
 };

希望使用功能的编程代码推广这些例子将激励你寻找在那里你可以在自己的代码相同的情况。

关于作者简介：： 约翰Lindal （ @ jafl5272在Twitter）是雅虎建设的基础上率先工程师之一 APT是建成。 此前，他曾在雅虎出版商网络。

找到的谈话： bloglines technorati

共享和扩展： 书签del.icio.us Digg它！ | reddit！

帮助我们帮助别人！

2012年4月25日，上午8:00 DAV玻璃| 开发 | 7评论

关于YUI的最好的事情之一是我们的文档。 它已经相识多年，该文件是为我们的开发在社会上的高优先级。 我们的其他优先事项之一，是特殊的API文档。 我们一直有高品质的文件，但是，谈到了价格标签，时间。

你知道吗，你可以帮助我们？

我们所有的文件可以在我们的Github上回购和我们使用的工具来生成这个文件是供您使用。 是的，这是正确的，我们使用的一切，使我们的文档是现在。 在这篇文章中，我会告诉你如何修复API文档和更新 ，以帮助其他开发商只喜欢你一个例子 。

这篇文章是关于修改现有的例子，着陆页和API文档。 退房底部的截屏，如果你是从头开始创建新的例子更感兴趣。

你需要什么？

你需要的安装Node.js的工作（建议使用0.6.x或更高）， 故宫 （节点打包）， 塞莱克 我们自定义的文档工具和YUIDoc 我们的API文档工具 。 这些工具都是免费提供和安装非常容易。 只是到这里，并选择您的环境安装Node.js. 一旦它的安装，您可以安装两个工具，用这个命令：

 npm -g install selleck yuidocjs 

一旦完成，你所有设置！

**你会的，当然，需要git的安装，有Github上的帐户，并已经分叉的yui3回购

那里的东西生活

我们所有的例子都保存在我们的主要源代码树，这使得它更容易联想到的代码，它属于一个例子。 在这个例子中，我将努力的 DragDrop例子和API文档。

主着陆页和示例文件位于yui3/src/dd/docs下。 所有的API文档进行解析从原始的源文件 （我们将位）。

见此呈现的例子

任何例子中最难的部分是看它的外观，一旦它准备。 这是其中塞莱克也发挥了作用。 塞莱克 “服务器模式”，您可以火起来看看我们的例子“解析和加载”。 谈到塞莱克的 “服务器模式”很简单：

 cd yui3/src; selleck --server 

这将打印到控制台以下：

 [info] Selleck is now giving Ferrari rides at http://localhost:3000 

现在在您选择的浏览器访问http://127.0.0.1:3000显示src目录下发现的所有组件的列表，你应该看到主塞莱克页。

如果你不想塞莱克绑定到3000端口，只需将上述命令（ selleck --server 5000端口）

使用塞莱克在服务器模式的优势之一是，你不需要重新启动服务器（除非你添加新的例子的JSON文件）看到你的变化。 只需打开一个文件，编辑，保存和重新加载！ 就是这么简单！

固定API文档

我们所有的API文档直接从我们的源文件进行解析yui3/src/dd/js与
YUIDoc 。 这使得他们读源文件有点困难（​​除非你能在你的脑袋JSDoc标签和降价语法解析）。 幸运的是YUIDoc也有帮助您与此服务器模式。 谈到对YUIDoc服务器模式是一样塞莱克的容易：

 cd yui3/src; yuidoc --server 

这将打印出结束与一些YUIDoc调试信息：

 info: (server): Starting server: http://127.0.0.1:3000 

现在，在您选择的浏览器访问http://127.0.0.1:3000 ，你应该看到主要YUIDoc页上市解析的API文档。

如果你不想YUIDoc绑定到3000端口，只需将上述命令（ yuidoc --server 5000端口）

YUIDoc的服务器模式的工作很多像塞莱克的，你不需要重新启动服务器来看到你的变化。YUIDoc将在每一页上的负载重新分析所有的源代码，并显示你更新的API文档。 只需打开一个文件，编辑，保存和重新加载！ 就是这么简单！

需要记住的事情

有些事情要记住，当你在你想要的东西贡献：

• 始终工作在一个分支git checkout -b mydocpatch
• 推到你的分支git push origin mydocpatch
• 提交你的分支拉请求
• （可选）如果你用git舒适，我们建议对yui/yui3的“活文件”分支工作

更新的东西后，我该怎么办？

与任何其他在YUI的，一旦你更新你的文件，只需提交他们发出我们像往常一样拉请求 。 我们的开发者之一，将核实的变化和合并他们或给你一些反馈。

如何往往是在网站上更新的东西吗？

我们当前的站点部署是很容易的，我们经常部署以yuilibrary.com至少每周一次。 有时候，我们甚至每天推！ 因此，您的更改，并回馈社会！

更多信息

YUI的工程师卢克·史密斯放在一起展示如何从头开始创建一个新的例子下面的屏幕投。 在它的外观和更多的视频接管我们的YouTube频道 。

找到的谈话： bloglines technorati

共享和扩展： 书签del.icio.us Digg它！ | reddit！

锐：周四4月26日营业时间

2012年4月23日下午10时30分由卢克·斯密在发展 ， 营业时间 | 评论

代码修改：照片我附近

在埃里克F的最近期的文章中，他报告了他的运动锐添加到他的项目的应用程序的服务器端，靠近我的照片。 简短形式：到目前为止，一切都很好。

这是一段时间以来，我们已经做了一个很好的老式代码审查，这似乎像一个完美的候选人。 服务器端锐，应用框架，台式机和移动的考虑，渐进增强。 这里有许多良好的外卖。

录音

录音是在YUILibrary YouTube频道 。

找到的谈话： bloglines technorati

共享和扩展： 书签del.icio.us Digg它！ | reddit！

在服务器上使用您的应用程序的YUI组件

2012年4月23日，在下午03:36由Eric Ferraiuolo在发展 ， YUI实现 | 5评论

3.6.0发展的第一个冲刺为我，我写了（例如显示）如何开发一个应用程序在客户端和服务器，台式机和移动设备上都使用YUI的。 代码共享和重用FTW！ 为了启动这一进程，我想首先建立的东西，用发展的办法，我们要促进。 我已经做了，我想我第一次的经验上运行的Node.js锐在报告（扰流：这是真棒！）

我附近的照片 ，一个应用程序，显示了您当前所在位置附近的有趣照片，是我差不多一年前开始到dogfood YUI应用程序框架，而瑞安树丛和我写的一个项目。 我一直在保持应用程序最新的最新变化和增加的应用程序框架，包括对的使用Y.App ，在应用框架的最新组成部分。 附近我的照片一直是客户端唯一的应用程序到现在为止！

我的计划是到附近我的照片服务器使用Node.js的，Express.js，和YUI的权力，我设置了两个目标：共享应用程序的模型对象和共享其把手的客户端和服务器之间的模板。 感谢DAV玻璃把一吨的努力，使锐Node.js的一个直观，无缝方式上运行 ，我是经过几个小时的重构应用程序能够轻松地完成这些目标。 我感到惊喜，我第一次尝试实例化一个服务器端的模型对象和调用它的load()方法，该方法从YQL的读取数据， 只是frickin的工作！

现在离我的照片呈现在服务器上的请求的初始状态，然后手断控制客户端Y.App实例。 从那里，在现代浏览器可以使用HTML5的历史，所有的路由，数据抓取，网页渲染，将客户端，而旧的浏览器将执行整版由服务器处理的负载。 从请求到看到照片的时间已大幅减少，这是我的iPhone时，清爽的页面上尤其明显。

能够使用完全相同的代码之间的客户端和服务器使模型和模板后，逐步增强，更容易实现最佳做法 。

退房近我的照片：
http://photosnear.me/

与资金来源：
https://github.com/ericf/photosnear.me

观看的全面建设与YUI的应用教程将使用附近我的照片，作为一个例子来描述，并显示在细节上的服务器和客户端建立在桌面和移动浏览器上运行的应用程序如何使用YUI的同时遵循的最佳做法渐进增强。

找到的谈话： bloglines technorati

共享和扩展： 书签del.icio.us Digg它！ | reddit！

迁移YUI的2至3锐：一个案例研究

2012年4月23日9:26 | 开发 | 2评论由约翰Lindal上午

当我坐下来建立了YUI 3版本的页面布局 ，我知道这将是一项艰巨的任务。 YUI 2版本，即使是其第三化身，代码仍然是一个烂摊子。 表现灾难的第二化身，大大简化了，原来的设计要求只基于行的布局，但后来有人需要一个基于列的布局，他们需要快速，而不是重构代码干净，我重复它改写布局引擎。 此外，我知道，只有这样，才能让人们从YUI 2版本迁移到了YUI 3版本将完全保持在YUI 3版本相同的API，所以没有人会要改写其代码。 更糟的是，锐2版本是一个全局对象自动实例化脚本时加载，所以应用程序代码可以配置和认购前domready事件的事件。 这个最坏的言下之意是，最初的对象，承担了基于行的布局，然后，domready事件中，如果检测到基于列的布局，对象默默取代本身，从旧的对象复制的设置！ （行和列的版本共享同一事件的对象，所以用户并没有受到影响。）

这一切考虑，我做的第一件事是无视这一切，因为我想获得YUI 3版本的权利。 我很满意与基本API，但两个副本和domready事件上的沉默切换不得不去。 由YUI 3插件架构的启发，我决定了理想的解决方案是将有一个单独的类，其中检测的布局类型，并用相应的布局引擎。 YUI加载器，甚至让我上加载的布局引擎的需求！ 花了几个星期分解两个YUI的2班，和它们合并成一个插件的单个类，但结果很干净，（只要你不看代码过于紧密的布局引擎插件）简单。

现在来了最困难的部分：如何使这一个下拉更换为YUI 2版本。 使用它的应用仍然有很多锐2中的代码，并不能引用Y ，所以YAHOO.APEX.PageLayout不得不被定义，它必须创建脚本加载时，它必须公开所有必需的功能和事件签名。 进一步蒙混过关的事情，YUI的事件签名锐2事件签名，从根本上不同。

也有另一种严重的并发症：锐3真的不喜欢全局对象。 一切Y Y沙箱创建YUI().use()通常是局限于YUI().use()

第一步是打破沙箱存储的实例Y.PageLayout在YUI.SATG.prototype.layout_mgr 。 （通过实例YUI.SATG ，每个沙箱开始用相同的初始值，然后可以安全修改Y.SATG不影响其它沙箱。当然，的覆盖Y.SATG.layout_mgr将是一个坏主意，但有其他的东西在这对象，太）。

打破沙箱是不是轻易进行。 最引人注目的问题是， instanceof沙箱之间传递的对象不起作用。 这是，灾难性Y.PageLayout.elementResized()因为参数，一个实例Y.Node ，可能是来自其他Y.PageLayout被实例化其中一个比一个沙箱。 值得庆幸的是，锐3.5.0切换instanceof Y.Node测试_node成员！

下一步，但只有当YAHOO.APEX.PageLayout YAHOO已经存在了，当然，定义YAHOO.APEX.PageLayout （ ）。 这个对象被证明是非常薄的，因为它只有作为继电器。 它存储引用函数在Y.PageLayout ，包括重命名的情侣，和实例YAHOO.util.CustomEvent 。

最后一步是订阅的事件Y.PageLayout ，重新打包数据，并触发相应的事件YAHOO.APEX.PageLayout 。 作为一个例子：

 page_layout.on（beforeResizeModule“功能（E）
 {
	 YAHOO.APEX.PageLayout.onBeforeResizeModule.fire（e.bd，e.height，e.width）;
 }）;

我希望这个概述我所面临的挑战将激励你，或至少使任务似乎不那么令人生畏，当你迁移到YUI的3。

关于作者简介：： 约翰Lindal （ @ jafl5272在Twitter）是雅虎建设的基础上率先工程师之一 APT是建成。 此前，他曾在雅虎出版商网络。

找到的谈话： bloglines technorati

共享和扩展： 书签del.icio.us Digg它！ | reddit！