解惑

解己之惑,解人之惑

标签:AJAX

jQuery成为新的AJAX基础库标杆

技术的发展真的是日新月异,AJAX开始风生水起的时候,prototype是AJAX基础库的标准,很多AJAX库都是基于它的,而现在,jQuery很可能会或者已经取代prototype成为AJAX基础库了。不知道是我太后知后觉还是技术发展实在太快,短短几个月的时间,我已经又不熟悉最新的AJAX动态了。
Ruby语言的特性(以$为标志)向JavaScript转移的风气愈演愈烈,本来我是对这种风格不太认同的,但是感觉必须接受了,在简单和可读性之间,我们是得做一些牺牲了,毕竟一个东西变成大家都熟悉并引以为标准后,它的可读性无形上就提高了很多,因为你读不懂,只能说明你落后了,或者变成新“文盲”了。

Web开发为什么没有UI的王者

做了这么多年的Web开发,感触最深的就是UI始终没有王者,虽然Web的Framework是一堆一堆,但是大家的注意力似乎都在MVC、Template以及Layout,以Java来说,历经了Servlet、JSP、TagLib以及JSF的变迁,当然其他的第三方的东西就更多的,但是就是没有一个成为事实标准,Struts勉强算一个强者,因为普及度最高,但是依然不能解决UI的表现力和交互性问题。我想这也是为什么现在AJAX以及RIA喧嚣尘上,但是无论是以JS为基础的AJAX还是RIA(以Flex和JavaXF为代表)的方案都不能解决全部的问题,无论是AJAX还是RIA,在交互性上都有不错的表现,特别是RIA,能够做出很酷很炫的界面,而以JS为基础的UI库也是不胜枚举,就是没有出现强者,各自分据一小块开发者。
这个问题应该是已经被问了无数次,但是迄今没有出来很好的方案,在最近的两年内都不太可能出现什么转机,唉。。。

更新:
下午看infoq刚好看到一个针对这个问题的访谈,访谈对象都是一些典型阵营的人,很有意思,看完的感受就是:各自力挺自家的方案。不管是否出于商业利益,这个访谈的结果只能更加证明web的UI端的混乱不会结束。也许不同的方案确实要应用到不同的场景,以内容为主的网站更加倾向于原来的HTML为主的方案,对交互性要求稍高的可能用AJAX,对交互性和表现力要求最高的就用RIA。

JSR168

JSR168规范是定义portlet容器及portlet之间的关系的,但是由于定稿比较早(2003年10月),所以没有涉及到portlet的独自渲染和刷新,而这个是现在的web2.0或者新一代web界面所不可或缺的,当然,新的JSR286规范可能会解决这个问题,但是我们不能等待这个规范的出台。就目前的情况看,融合jsr168和AJAX并不会很困难,问题的关键是没有一个轻量的组件或者成熟的解决方案,有的只是大的软件厂商在他们的portal产品中提供这种特性的支持。这段时间一直在用pluto,刚刚整合到我们的系统中,看了下pluto最终渲染出来的页面片断:
  <!– Assemble the rendering result –><br />
 
<div id="/testsuite.TestPortlet!764587357|0" class="portlet"><br />
  
<div class="header"><br />
      <!– Portlet Mode Controls –><br />
      <a href="http://localhost:8080/pluto/portal/__pm0x3testsuite0x2TestPortlet1!764587357|0_view"><span class="view"></span></a><br />
      <a href="http://localhost:8080/pluto/portal/__pm0x3testsuite0x2TestPortlet1!764587357|0_edit"><span class="edit"></span></a><br />
      <a href="http://localhost:8080/pluto/portal/__pm0x3testsuite0x2TestPortlet1!764587357|0_help"><span class="help"></span></a><br />
      <!– Window State Controls –><br />
      <a href="http://localhost:8080/pluto/portal/__ws0x3testsuite0x2TestPortlet1!764587357|0_minimized"><span class="min"></span></a><br />
      <a href="http://localhost:8080/pluto/portal/__ws0x3testsuite0x2TestPortlet1!764587357|0_maximized"><span class="max"></span></a><br />
      <a href="http://localhost:8080/pluto/portal/__ws0x3testsuite0x2TestPortlet1!764587357|0_normal"><span class="norm"></span></a><br />
      <!– Portlet Title –><br />
    
<h2 class="title">Test Portlet #1</h2>
<br />
    </div>
<br />
  
<div class="body"><br />
从这个输出来看,我们需要做的可能很简单,替换portlet-skin.jsp,重新定义那些按钮的输出为一个javascript,这样应该就可以部分刷新了。目前我们产品的其它一个功能已经可以做到这个了。现在的问题就是转换了。

关于AJAX的一些思考

公司的产品中也引入了AJAX,但是是很简单的,代码都是自己写的,开发经理Paul看到Yahoo的新邮箱后感觉不错,期望我们也使用AJAX(实际上我们已经在使用了)。
使用AJAX,个人感觉有一些问题,首先就是开发难度,JavaScript的调试比较困难(相对于Java),而且还要解决浏览器兼容问题,另外一个就是性能,如果使用不好,对于性能反到是有害的,很多站点的解决方案都是一个大框架页面,剩下的块块都是使用AJAX一个一个加载(我们也是),这个对服务器端的负载实际是加重了。
当然也并非没有办法解决,首先就是要有一个合适的AJAX的框架,开发人员需要考虑的问题相对较少;其次就是和服务器端的交互,可以使用某种客户端缓存机制减轻负载并加快用户操作的相应时间。如果页面一直保持不完全刷新,那么这样的AJAX方案还是可以接受的,最怕的就是要经常完全刷新页面,或者是internet应用,需要对搜索引擎友好。

推荐一个AJAX相关的JS库:setInnerHTML

>跨浏览器的设置innerHTML方法

这个JS库是无意中发现的,而且刚好我们的产品要引入AJAX,但是我们又不能使用纯粹的AJAX方案,因为我们的产品已经开发了很长时间了,服务器端返回的是HTML,要专门为引入的AJAX返回特殊的内容工作量比较大,但是由于返回的HTML比较复杂,还可能包含了JS文件的引用以及JS代码,所以在IE下或者FF下总是有这样那样的问题,这个JS库的引入很好的解决了我们面临的问题,推荐在已有B/S产品或者项目中引入AJAX特性的项目使用这个解决方案。

© 2024 解惑

本主题由Anders Noren提供向上 ↑