JSF+AJAX企业级开发之路——来自Sun的高级工程师Ed Burns的精彩演讲【二】

JSF+AJAX企业级开发之路——来自Sun的高级工程师Ed Burns的精彩演讲【二】

关键字: enterprise grade ajax and jsf

Ed Burns在本小节中的论述比较精彩，提到了各种AJAX整合JSF的方案以及AJAX的常见问答．因为我一直是用Webwork/Struts2，对JSF接触并不深．为此花了不小时间来“扫盲”．Ed来谈到了JCP也想搞一个AJAX+JSF的东东，并且集百家之长，但从他不愿意透露更多，可以看出还是有得等了．在对JSF2.0的憧憬，Ed想将现在JSF的Server-centric（请看注1）慢慢转成Cliene-centric，注意这是否意味着Cliene-centric会是将来AJAX的趋势？好了，快开始吧．

正文

现在，更高级别的JSF+AJAX整合方式到来了。确切的说，这种更加容易使用的解决方案就是在使用JSF基础上再加上AJAX扩展。我上面已经提到了，现在有很多的解决方案了，今天我要谈论的是其中之一的Project Dynamic Faces。当你在使用这些解决方案时，通常是不需要去了解任何JavaScript知识的，因为它已经为你封装好JavaScript的编程实现，你只需要正常使用JSF的API去编程，就能达到AJAX的效果。当然，你如果需要的话，Dynamic Faces也是允许你去手工编写JavaScript的，（通过自己编写的JavaScript）你可以实现更强大复杂的操作。据我所之Dynamic Faces是目前为止唯一一个可以正确处理JSF上下文敏感（context sensitive）的AJAX交互组件，原因是它充分利用了JSF1.2的优势（注：虽然专家组们在讨论JSF2.0规范，但现在实际使用的JSF最新版本是1.2）。现在我们来看一个demo，假设说你有一个数据列表，当你随便碰到某个单元格时（注：类似于操作Excel．当我们在使用Excel的时候，光标所移动到的任何单元则都是可以随便操作，并保存的），你想通过AJAX去处理你所指定的那个单元格时，所有的单元格的在页面渲染完后状态都是可随时存储的，便于随时修改，此时显示在页面的data table(数据表格)就是dataset所持有的数据呈现给外部的一个窗口；当你在修改完data table的某行记录或某行记录中的某列后，想postback一下（注：postback指的是用户返回到以前访问过的一个页面，与页面对应的视图已经存在，所以只需恢复它。在这种情况下，JSF 使用现有视图的状态信息重新构造它的状态。）这时你需要将data table设置成自身，从而可以感知到改动的数据．JSF1.2已经添加了一些新特性来支持这样的应用场合．这还得多亏我们的专家组成员Jacob Hookom，同时他也是Facelets的作者．（注：Facelets是用来建立JSF应用程序时的一个可供选择的表现层技术） 我之所以为Dynamic Faces亮起红灯（表示警告），是因为JSF1.2有这个特性，它才能实现这个功能，而且还不是很成熟。虽然它现在当已经加入到Sun Web Developer Pack中去了，不过仍然处于0.1版本，与其它你可能听说过的AJAX解决方案相比，缺乏大量的测试。 下一级别的的JSF+AJAX整合方案就是直接使用带AJAX的JSF组件。用这类组件，与使用普通的JSF组件没有什么两样，实际上它们已经将AJAX所做的事都全部为你封装好了。这些组件也许会通过phase listener，filter或者其它什么配置来处理AJAX请求，但不需要你亲自去处理。现在已经有一些不错的组件可以使用了，而且相当一部分还支持JSF1.1。这些组件中，有些是开源的，有些要付费的，总之这是一个相当大的市场，你可以登录www.jsfcentral.com，这是由另一名专家组成员Kito Mann运作的，里面有很多非常优秀的组件，并且你还可以从中了解目前JSF组件的市场行情。 退一步说，如果在众多JSF组件中，仍然没有让你感到满意的话，你就得亲自写代码了，要不然用DynaFacesr扩展也是可以的。 好了，到这里，当我在考虑JSF整合AJAX这部分的时候，一个大难题浮现在我脑中：是应该支持各种途径去使用AJAX（比如说允许自己编写客户端代码）呢，还是像通常的web应用程序那样，只采用UI标签方式呢？我的观点是，不支持，没有必要。关于这个点会在小组讨论中谈到。如果采用Dojo方式的话，你的大量ViewLogic(页面逻辑)绑定在客户端上，这样做也许只是将服务器变得负担轻一些；而使用GWT的话，你得将Java编译成JavaScript代码，但此时的JavaScript仍然运行在客户端，然后使用一个类似于RMI的机制通过服务器端来来回回不停的调用。但以上这些只是考虑了客户端这个方面！另一方面，你仍然可以使用基于服务端开发工具，去开发你的组件，然后markup(标记)在服务端上，这样就可以通过服务端呈现给客户端，这一类的解决方案的思想就是将UI组件的状态保存在服务端．我也觉得无论从成熟度，相应工具的支持程度还是可维护性上来说，这样做都有很大的优势．按照我的话来说，将大量的UI组件逻辑保存在服务器上，你会发现更加易去维护． 因此，对于上述问题的一种解决办法是，把JSF当作web应用程序开发的基础，并且你只需要在此基础上略施小计就可以得到AJAX支持．JSF的AJAX扩展就是这么实现的，我现在将一些熟悉的扩展列出来：Dynamic Faces，ICEfaces，AJAX for JSF（现在和JBoss搭上了伙，成为了RichFaces），BackBase还JackBe.．总之,在www.jsfmatrix.net站点可以看到这些解决方案之间的比较．另一个不错的解决办法来自于JCP，我们会将现在上面列出的那些扩展中先进的思想提交给JSF专家组，并且我们正准做出更多的努力，但现在无法透露太多。（看来JCP的专家组们还是没有改变办事过于拖拉的毛病，因此估计官方的AJAX+JSF方案一时半会是出不来了。） 那么为什么从设计的角度就要将JSF和AJAX整合在一起呢？因为JSF天生有着Swing的特性，如果你喜欢采用基于组件的面向对象方式进行编程，你会发现JSF的设计就是为AJAX而准备的．一些JSF的特性使得AJAX变得更加友好并进一步扩展了JSF UI组件模型；一个建立在servlet之上，定义良好的请求处理生存周期（request processing life cycle）管理着WebRequest各种状态(phase)下不同的生存周期，比起单纯的request, response要丰富的多，甚至我感觉这一点在脱离JSF仍然十分有用．那就是我们打算让JSF2.0应用程序以更加偏重于client-centric方式（请看注1，但从目前情况来看JSF仍然属于server-centric）来贯穿整个JSF生存周期，甚至到时候要不要JSF组件都说不定了，但验证和类型转换等这类东西还是需要的． 另一个特性就是灵活和可扩展的组件呈现模型（Rendering Model）．Rendering的概念源于组件，你可以用render kits(套件)去丰富基于JavaScript的应用程序，与HTML4.01相比，它的内容更加丰富。各种各样的render kits为你隐藏了复杂的底层细节，帮助你实现网站的多种版本。这里还有一个关于封装的概念：JavaScript的封装不应该交给页面的编写人员，应该交给组件开发人员，最终所有的JSF组件统一管理在一起，更加方便透明的保持客户端与服务器之间的同步。现在我们来看一些典型的AJAX问题与解答： 1. 跨浏览器问题，通过封装好的JavaScript框架已经很可做到这一点了2. 本地化和国际化问题，用JSF就可以搞定了，AJAX根本不需要参与3. Shell remoting的机制就是专门用来管理脚本，它用一种安全的方式为你的组件提供存放在class path外面的JavaScript脚本．（更多关于AJAX remoting请看注2）4. 如果你觉得你写了太多的XMLHttpRequest来来回回与服务器进行交互的话，你可以使用Dynamic Faces的批处理事件（或找一个具备批处理事件的类似替换物），一次性将所有的事件发送完成．5. 使用XML作为（AJAX与服务器交互后的返回的）传输数据的话，要求对于某些HTML元素做一些额外的优化工作．比如说，&nbsp 是HTML的一个实体，但它在XML中却什么都不是．当XMLHttpRequest的responseXML包含&nbsp的话，Mozilla浏览器将无法正常解析XML，它会认为这是一个无效的实体，因此，我不知道你们是不是也觉得这算是Mozilla的一个Bug呢？此时你必要按照某种方式去定义那些东西，并且确保这类问题通过AJAX+JSF的方案来解决．为现有的或即将立项的JSF应用程序插上AJAX翅膀，我个人觉得对于应用程序来说非常棒．我想我们应该可以做到让一个已经完成的项目AJAX化（AJAXify），并且如果是新的项目的话，保证还能从中得到更多的好处．这一切还得再次得归功Jacob Hookom天才的理念。我觉得他的Project Dynamic Faces为开发人员朝着AJAX方向前进了一小步．真的！！！就两个JSP Tag和两个JavaScript Function需要你掌握，但就是这小小的一步，你也已经可以从中得到很多AJAX特性了． 因此，这里有一个基本的概念．将JSF的生存周期通过AJAX暴露给浏览器，并且你想通过AJAX来操作整个View或其中的某个部分，从而达到更新一块单独的View区域或某个组件的目的，或者干脆越过AJAX来刷新整个页面也能实现。有时候，你希望通过使用AJAX可以越过JSF的生存周期，来取得一些控制级别并且你还可以让服务器（在不刷新页面的情况下）来改变当前页面的外观或行为．通常这对于Swing或其它native UI Tookit开人员来说，很好理解：当前窗体的部分外观或行为被更新过了，服务器当然只会去对那部分作一下修改，犯不着整个窗体都重新更新一遍。现在将这个观念带回到Web开发中来，页面的部分内容或行为改变了，你重绘(repaint)一下不就得了。

　未完待续 注1: 所谓 Client-centric 是指你写的程序代码(UI部份)主要执行的地方在客户端 (即浏览器)，而 Server-centric 则在服务器端。大部份框架多是 Client-centric，如Dojo, Prototype，GWT，Ext-JS，Backbase等。而Server-centric则以ZK为代表 注2: 由于最后发行的 JSF 规范几乎与 Ajax 重合，JSF 框架在异步 javascript 和局部页面呈现（partial page rendering）方面帮助不大。在某些时候，甚至这两种类型的编程甚至不一致。最终的解决办法是建议使用 JSF PhaseListener 或组件 Renderer 来处理局部页面更新。即使如此，这一点仍然很明显：JSF 使得 Ajax 比过去更难于采用。有些项目，例如 ICEfaces，甚至用一个更好的、专为页面－服务器通信设计的技术（即 direct-to-DOM rendering）来替代 JSF 生命周期。 Seam 为 JavaScript remoting（经常记在 Ajax 名下的一种技术）提供了一种独特的方式，该方式与 Direct Web Remoting (DWR) 库的方式大致相似。Seam 通过答应 JavaScript 直接调用服务器组件上的方法，将客户机与服务器连在一起。Seam remoting 比 DWR 更强大，因为它可以访问丰富的上下文组件模型，而不仅仅是一个孤立的端点。这种交互构建在 JSF 的事件驱动设计的基础上，所以它可以更严格地遵从 Swing 范例。最妙的是，提供这个功能的同时并没有增加开发方面的负担。只需在组件的方法上加一个简单的注释 @WebRemote，JavaScript 就可以访问该方法。当服务器组件的状态被修改之后，Ajax4JSF 组件库就可以处理局部呈现。简言之：Seam remoting 库使 JSF 可以实现它的创立者一向期望的交互设计。