怎样的AJAX才算是理想?
要说什么是理想的ASP.NET AJAX,就要先说说什么是理想的AJAX。事实上AJAX最不理想的地方在于search engine friendly以及bookmarkable,这两个问题有一定的相似性,要解决并不难,只是每一个系统中实现起来都不一样,因此难以提出一个统一的patterns来解决。
首先说说search engine friendly这一点吧,实际上使用了AJAX的站点有很多信息是搜索引擎无法索引到的,因为页面上部分的信息是在用户进行操作后才显示的,显示的这些信息有可能是固定的也有可能是经过XHR(XMLHttpRequest)查询服务器后动态显示的。如果是固定信息,那么在生成页面时就要考虑这些信息是否也应该输出为静态HTML。那么什么情况下该输出为静态HTML而什么情况下不该输出为静态HTML呢?我觉得应该看隐藏的内容是否就是页面语义的一部分。例如页面用于显示一张集体照,当鼠标指向照片上不同人物时将显示他们的姓名和有关的介绍,那么这些信息就应该输出为静态HTML了,因为它们是页面信息的重要组成部分,并且这些信息应该被搜索引擎索引到。
当然,事情并非任何时候都那么简单,有时候我们并不能简单判断某些信息是否应该属于一个页面,或者说一个URL。例如你使用一个页面来展示你的gallery,但并非一下子显示所有的照片,开头显示随机的10张图片,然后允许用户输入/选择tag来显示对应的照片,如果当前显示的照片超过10张还会自动分页。这时候怎么办呢?整个gallery输出的一个静态页包括所有的照片以及描述?这看起来不太可行。假如你的gallery有100个tag和1000张照片,同时这一个页面成功被搜索引擎索引了,用户通过搜索引擎来到gallery页,他怎么找到搜索引擎上匹配的图片以及对应的描述?他根本不可能知道他要找的信息藏在哪里了,100个tag中可能只有几个能让他想找的信息显示出来。
这时候比较好的做法就是将tag分离出来变成独立的页面,或者说是URL。gallery首页上的tag对于用户来说是交互式按钮,在不刷新的情况下直接筛选对应的照片;但对于搜索引擎来说那是链接,链接到代表该筛选状态的页面,并且在该页面上才索引到照片和描述。这样当用户点击特定的搜索结果是,进入的是已经筛选了的gallery结果页,也就必然能看到他搜索命中的信息。同时这也增加了bookmarkable的可能性,因为一个URL已经不仅仅代表一个页面,而代表一个页面的特定状态,因此状态变得bookmarkable。然而这时候普通的筛选结果还不是bookmarkable的,因为在进行根据tag筛选后URL是不会被改变的,因此我们必须通过JavaScript改变URL才能让页面变得bookmarkable。
与理想的距离有多远?
我们面临最大的问题就是URL与状态的对应,以及有关的存取。我们希望每一个indexable & bookmarkable的状态都对应一个URL,而且最好是meaningful的URL。好吧,我们先舍弃meaningful这一点来探讨状态问题,实际上我们已经有一些方法来保存状态。例如ASP.NET提供的ViewState就是一个很好的例子。很多ASP.NET的新手可能会觉得要理解如何正确使用ViewState并不容易,其实它就是用于保存view的state的。整台计算机其实也就是一个state machine,不过我们当前所关注的是与view有关的state,所以称之为ViewState。ASP.NET开头的策略是在服务器端处理一切,所以发明了ViewState并尝试让状态在客户端仅作持久不作修改。然而我们需要的正好是相反的,我们需要一个在客户端能修改的状态,并且以URL作为持久的方式。
首先,我们不可能好像ASP.NET保存ViewState那样保存数据到URL当中。即使我们舍弃了meaningful,ViewState的容量还是会超过URL的长度限制,因此希望好像ASP.NET那样每一个控件各自汇报自己的ViewState然后页面负责统一持久到URL是难以实现的。(当然,在ASP.NET AJAX中尝试一下这样的实现也未尝不可,虽然其提供的控件少之又少。)
既然我们不能够好像ASP.NET保存ViewState那样“放肆”地利用URL进行持久,那么我们就必须针对特定的应用来考虑持久的方式,这正是无法开发一个通用框架实现此功能的原因。例如上面所说的gallery,我们要人为的考虑使用tag作为区分view的一个状态参数,接着我们可能还要考虑当用户选中多个view之后会发生什么事,是不是简单的在URL里面叠加多个tag呢?例如gallery.html#fun+event的样子?那么它和gallery.html#event+fun是等效的,而两个URL会不会导致PageRank的分散呢?之后又如何加上分页参数呢?这一切问题不是没有答案,而是它们的答案都太具针对性了,因此不具有通用性,难以做成一个可复用的框架实现。
因此我们在这里能做到的最多就如ASP.NET Futures或者别的框架提供的history功能那样,提供一个有限容量的string空间给你,你要自己决定如何把状态转换为string然后提交给它保存,之后它保你实现跨浏览器的Permanent URL和history支持。
到此为止,我们站在client centric的角度讨论了AJAX现在面临的一些重要障碍,以及潜在的解决方案。下一part我们将从server centric的角度来继续研究这个问题,并探讨ASP.NET是否能在AJAX方面做得更好,又或者是别的Microsoft技术。继续关注本文章系列,欢迎订阅Cat in Chinese(feed)或Cat in dotNET(feed)。
没有评论:
发表评论