当我们在最开始接触ASP.NET时,除了被.NET的整个框架和code-behind的代码方式吸引之外,同时对一些M$提供的cookies也非常的欣赏。其中SmartNavigation特性就是大家印象比较深的,不过这个cookie的使用和它受到的期望却相去甚远,这是为什么呢?微软在Framework 2.0里又是怎对待它的呢?
关于Page类的SmartNavigation属性的原理、问题以及改进,我曾写了一个系列文章在2004年9月份,同时有幸受约发表于《开发高手》期刊。现在来看Fx1.0/1.1中实现的SmartNavigation特性,用一句话:中看不中用。来评价,是不算太过分的。虽然这个功能的创意和实现是挺不错的,不过它实际使用的问题实在是太多了,可以看看这篇文章了解一二。那么我们在Framework 2.0 beta2中,还要继续使用这个特性吗?
现在我们在Framework 2.0 beta2中再使用SmartNavigation特性,将会得到一个编译时warning。因为Page.SmartNavigation这个属性已被标注为Obsolete了。同时,Framework 2.0建议我们使用一个叫做MaintainScrollPositionOnPostBack的Page属性来代替SmartNavigation。名字真是无比的啰嗦,它是干什么的呢?就做和我后来弄个那个ClientNavigation一样的事情,在页面提交后,保持Scroll Bar的位置在新的Response页面中。
MaintainScrollPositionOnPostBack的实现原理和ClientNavigation基本相同,区别是前者是通过处理Page,即整个页面的返回内容的更改来实现的,而ClientNavigation以一个控件方式提供。这都无所谓了,具体看了一下前者的实现,还是有一个地方是值得学习的,就是获取ScrollBar的位置的代码,代码片断如下:
{
if (__nonMSDOMBrowser)
{
return window.pageXOffset;
}
else
{
if (document.documentElement && document.documentElement.scrollLeft)
{
return document.documentElement.scrollLeft;
}
else if (document.body)
{
return document.body.scrollLeft;
}
}
return 0;
}
如此简单的代码,有什么问题呢?只细看else分支,为什么不直接返回document.body.scrollLeft,要啰哩啰唆搞得这么复杂?因为这里有一个IE的bug(我曾在开发TreeView控件,然后把TreeView放在Frame中时遇到过),在某些情况下,我们滚动了滚动条通过document.body.scrollLeft取不到ScrollBar的位置值,这个属性总是为"0"。那么我们就都用document.documentElement.scrollLeft来取不就行吗了?这里这样做微软是为了考虑向下兼容性,因为document.documentElement属性是IE5.0以后才提供的。另外就是,回传的ScrollBar位置,通过两个预置的hide field搞定:
< input type ="hidden" name ="__SCROLLPOSITIONY" id ="__SCROLLPOSITIONY" value ="365" />
MaintainScrollPositionOnPostBack和ClientNavigation都是一种非常轻便的解决方法,使用这种新的方法,基本避免了原来SmartNavigation中的所有问题,同时MaintainScrollPositionOnPostBack还支持cross-browser。新实现方式,唯一的一个小问题是如果页面篇幅太长或载入速度太慢,会有一个页面跳跃的扰动,当然这点小缺陷和正确、稳定、轻便比起来就不是什么大问题了。