Sys.UI.Data.DataNavigator与Sys.UI.Data.SortBehavior
2006-09-28 16:28 by 老赵, 2807 visits这次我想讨论与分析的内容是Sys.UI.Data.DataNavigator与Sys.UI.Data.SortBehavior。在这之前，可能感兴趣的朋友们需要先了解一下Atlas Client Script中Data Control的使用方法。可以先学习一些别的文章，例如官方说明《Start > Quickstart Developer Tasks > Performing Data Access》，而Dflying兄的Atlas介绍系列也实属精品。
Sys.UI.Data.DataNavigator和Sys.UI.Data.SortBehavior的作用都是配合DataView进行数据操作：一个操作分页功能，一个操作排序功能。事实上这两个类都是属于辅助类，它们的功能是更加方便了开发，而提供的额外功能却不多。
Sys.UI.Data.SortBehavior使用了DataView的自带的属性与方法为DataView的内容进行了排序。当一个SortBehavior被应用到了一个控件时，它会根据控件的点击来决定DataView的排序顺序（在ASC和SESC之间切换），并且根据当前的排序顺序为control应用不同的样式（sortAscendingCssClass或sortDescendingCssClass）。如果没有这个控件，我们可能就需要配合使用setProperty，invokeMethod进行较为复杂的应用了。换个角度说，如果某个功能比较复杂并且需要复用的话，我们可以像SortBehavior一样封装起一系列操作。
Atlas中的控件设计并不随意，而是实实在在地“有用”。
但是，与Sys.UI.Data.SortBehavior相比，Sys.UI.Data.DataNavigator就有些古怪了。
Sys.UI.Data.DataNavigator提供了DataView的分页功能，不过无论是上一页也好，最后一页也罢，它的实现其实只是简单的使用了DataView的一个函数：set_pageIndex。配合get_pageIndex获得当前的页数，实现这些功能自不必说。不过非常有趣（或者继续使用上面的说法：古怪）的是触发DataNavigator那些功能的方式。DataNavigator没有提供任何的方法来触发它的那些操作，它的那些操作都是定义在DataNavigator的onBubbleEvent方法中。它的onBubbleEvent里判断了Sys.UI.Button对象传给它的Sys.UI.CommandEventArgs对象中commandName属性的值，然后进行不同的操作。
onBubbleEvent是我觉得在Atlas中比较奇特的玩意儿之一。它是定义在Sys.UI.Control类中的虚函数，直接或间接继承Sys.UI.Control的类可以对它进行重载。不过在代码中并不会调用onBubbleEvent，如果需要bubble event，那么就需要调用定义在Sys.UI.Control类中的raiseBubbleEvent方法。熟悉ASP.NET Server Control开发的朋友们应该可以发现这和ASP.NET中System.Web.UI.Control的OnBubbleEvent和RaiseBubbleEvent非常的类似，只可惜在Javascript中无法定义protected方法，只得把它们暴露在外了。
可以看出Atlas有多么深厚的ASP.NET背景。与ASP.NET一样，Atlas中的raiseBubbleEvent方法也不是个虚函数，它的定义无法改变，我们来看一下它的代码：
var currentTarget = this.get_parent();
while (currentTarget) {
if (currentTarget.onBubbleEvent(source, args)) {
return;
}
currentTarget = currentTarget.get_parent();
}
}
从当前控件开始，调用onBubbleEvent方法，如果返回false，则继续向parent传递，这样event就被bubble了。这是很标准的raiseBubbleEvent功能实现。
但是事情没有这么简单。在raiseBubbleEvent中可以看出，代码是通过parent属性获得上一级控件的引用。parent也是个无法重载的非虚成员，它定义在Sys.UI.Control中。不知道为什么，在官方的Client Library中缺少这个属性。我们来看一下它的实现。
if (_parent) {
return _parent;
}
else {
var parentElement = this.element.parentNode;
while (parentElement) {
if (parentElement.control) {
return parentElement.control;
}
parentElement = parentElement.parentNode;
}
return null;
}
}
可以看出这个属性的逻辑，如果曾经定义了parent，那么就返回parent引用，如果没有的话，那么就沿着DOM向父级元素找，找到第一个具有Atlas控件对象的元素。因此可以发现，parent并不需要被强制定义。为了证实这一点，在这里我借用一下Dflying兄在其文章《使用ASP.NET Atlas PageNavigator控件实现客户端分页导航》中编写的例子，我将对其进行简单的修改。
在Dflying兄的例子里有如下的定义：
<div id="pageNavigator">
<input type="button" id="btnFirstPage" value="<<" />
<input type="button" id="btnPrevPage" value="<" />
<span id="lblPageNumber"></span> / <span id="lblPageCount"></span>
<input type="button" id="btnNextPage" value=">" />
<input type="button" id="btnLastPage" value=">>" />
</div>
<script type="text/xml-script">
<page xmlns:script="http://schemas.microsoft.com/xml-script/2005">
<components>
...
<dataNavigator id="pageNavigator" dataView="view" />
<button id="btnFirstPage" parent="pageNavigator" command="FirstPage" />
<button id="btnPrevPage" parent="pageNavigator" command="PreviousPage">
...
</button>
<button id="btnNextPage" parent="pageNavigator" command="NextPage">
...
</button>
<button id="btnLastPage" parent="pageNavigator" command="LastPage" />
...
</components>
</page>
</script>
在这里，dataNavigator是那些<input type="button" />的父结点，而在Atlas Xml Scripts中也为每个button指定了自身的parent属性。我们先尝试着去除上方HTML定义的元素父子关系，保留下方Script不变：
<input type="button" id="btnFirstPage" value="<<" />
<input type="button" id="btnPrevPage" value="<" />
<span id="lblPageNumber"></span> / <span id="lblPageCount"></span>
<input type="button" id="btnNextPage" value=">" />
<input type="button" id="btnLastPage" value=">>" />
运行，一切正常。可以发现作为dataNavigator的元素无需为那些button的父结点。
接着，我们保留HTML元素的父子关系，在下方撤销在Atlas Scripts中的parent定义，如下：
<page xmlns:script="http://schemas.microsoft.com/xml-script/2005">
<components>
...
<dataNavigator id="pageNavigator" dataView="view" />
<button id="btnFirstPage"
<button id="btnPrevPage"
...
</button>
<button id="btnNextPage"
...
</button>
<button id="btnLastPage"
...
</components>
</page>
</script>
运行，依旧一切正常。可见，Atlas会自动在DOM树中寻找作为dataNavigator的control。感兴趣的朋友也可以尝试着将上述两者都去除，这样分页功能就会失效了。
不过，我的疑惑也就出现了……既然这样，为什么DataNavigator要设计成为一个控件？很明显，它只是提供了一个分页功能，而不具备任何显示作用！我们可以在任意一个地方定义任意一个元素作为所谓的“DataNavigator”，还是能够实现分页。从这一点上说，我们完全可以定义个类似于DataNavBehavior的东西来实现相同的效果。还有，为什么要使用bubble event的方式来作为实现DataNavigator的功能呢？纵观所有的Atlas控件，只有button一个类调用了raiseBubbleEvent方法，而在PageNavigator中直接把args参数作为CommandEventArgs对象来处理，这表明它已经作为一个特定实现而出现了。
有时候我想，DataNavigator的这个设计，莫非只是为了“演示”一下raiseBubbleEvent和onBubbleEvent的方式？事实上，DataNavigator只是集中了分页的功能，通过一个独立的对象来管理了操作，照这样说，我们可以为它提供相关方法或属性，然后依靠Button来invokeMethod或者setProperty。另外，熟悉ASP.NET Server Control开发的朋友们可以知道，在ASP.NET中RaiseBubbleEvent和OnBubbleEvent的作用是为了配合PostBack模型，在复合控件中将子控件的事件向父控件传递的一种方式。而在Client端，根本不需要这样的做法，所有的控件都是顶级元素，都能被直接访问并且注册事件，这样raiseBubbleEvent和onBubbleEvent方法似乎也就没有什么必要性了。
目前DataNavigator的设计，似乎只有在资源消耗上小一些。
不过现在，在Client端存在raiseBubbleEvent和onBubbleEvent的必要性，它们能否带来开发概念和方式上的改变，以及如何正确地使用它们，这些事情还在我脑子里激烈地进行着斗争，可能我以后会单独写一篇文章来仔细讨论这点。
似乎这片文章已经完成使命了，不过，事实上，在这里我还想提一下DataNavigator的一个bug。DataNavigator的部分代码如下：
2 Sys.UI.Data.DataNavigator.initializeBase(this, [associatedElement]);
3
4 ...
5
6 this.getDescriptor = function() {
7 var td = Sys.UI.Data.DataControl.callBaseMethod(this, 'getDescriptor');
8
9 td.addProperty('dataView', Object);
10
11 return td;
12 }
13 Sys.UI.Data.DataNavigator.registerBaseMethod(this, 'getDescriptor');
14
15 this.onBubbleEvent = function(source, args) {
16 ...
17 }
18 Sys.UI.Control.registerBaseMethod(this, 'onBubbleEvent');
19 }
20 Sys.UI.Data.DataNavigator.registerClass('Sys.UI.Data.DataNavigator', Sys.UI.Control);
看看第5行和第18行的代码，是不是觉得很奇怪？还好，由于DataNavigator是继承了Sys.UI.Control类，因此在运行效果上没有什么问题。幸甚！
哎，人气好差。到底是我真的写的不好，还是大家搞Atlas的热情退了呢？难以想象以前的火爆样啊……