dwr

原文： http://www.abigdreamer.com/mywork/webqq-update-online-reverse-ajax-implementation-off-the-assembly-line-simulation.html 本blog已转移到 造梦师 http://www.abigdreamer.com ，欢迎大家常去我的blog看看！ 说明：本次更新只是模拟了一下人员的上下线，并没有采用真是的数据（我一台电脑开那么多浏览器测试的话有点受不了，谁叫电脑烂呢，呵呵） 。另外需要注意的就是，需要用这个新的dwr.jar覆盖掉原来的那个dwr.jar，要不会出问题的！ 有朋友问我怎样用反向AJAX来实现在线人员列表的更新，提到DWR允许javascript访问服务器端的Java方法，这使得AJAX使用起来会比较容易，而在DWR2.0里面添加了一个非常强大的功能——反向AJAX，也就是说，服务器端的Java方法可以取得浏览器端的Web上下文，并可以调用javascript的方法，将服务器端的数据异步地传输给浏览器。本文将通过一个demo展示这种特性。这个demo实现了类似股票交易系统中实时更新数据的功能，事实上是通过发布-订阅模式去实现的。也就是说，客户端订阅一个主题，服务器端通过一个线程向订阅这个主题的浏览器定时、异步地发送数据，从而实现了这种实时更新的功能。

1. ScriptSession使用中存在的问题 在上一节实现了服务器的推送功能，但是根据 ScriptSession的生命周期我们可以得出以下几点的问题： （1）ScriptSession不会与HttpSession同时创建 当我们访问一个页面的时候，如果是第一次访问，就会创建一个新的HttpSession,之后再访问的时候，就会保持当前的Session,即使是刷新，也能保持当前的HttpSession。 但是，ScriptSession不同，第一次访问，会创建一个ScriptSession,但是，如果你刷新，就会创建一个新的ScriptSession. （2）如何得到ScriptSession 在DWR中，我们可以通过WebContextFactory.get()来取得一个WebContext对象，进而通过WebContext的getScriptSession()取得ScriptSession对象。 但是要注意，在我们自定义的Servlet中，我们也可以通过WebContextFactory.get()来取得一个WebContext,但是这种方法却不能取得ScriptSession对象。因为，此WebContext对象其实不是通过DWR的上下文环境得到的，所以，就根本没有创建ScriptSession对象。 假设这种方式也能得到ScriptSession的话，那么我们实现“推

在开始本节内容之前，先来了解一下什么是服务器推送技术和DWR的推送方式。 1.服务器推送技术和DWR的推送方式 传统模式的 Web 系统以客户端发出请求、服务器端响应的方式工作，服务端不能主动发送请求(消息)给客户端。 这种方式并不能满足很多现实应用的需求，譬如： 监控系统：后台硬件热插拔、LED、温度、电压发生变化； 即时通信系统：其它用户登录、发送信息； 即时报价系统：后台数据库内容发生变化； 　　这些应用都需要服务器能实时地将更新的信息传送到客户端，而无须客户端发出请求。“服务器推”技术在现实应用中有一些解决方案，这些解决方案大致可以分为两类： 一类需要在浏览器端安装插件，基于套接口（Socket）传送信息，或是使用 RMI、CORBA 进行远程调用；而另一类则无须浏览器安装任何插件、基于 HTTP 长连接。 　　而基于客户端套接口的“服务器推”技术大体可以分为: 　　　　1.传统轮询：在 Web 早期，这一点常使用 meta 刷新实现。这将自动指示浏览器在指定秒数之后重新装载页面，从而支持简陋的轮询（ polling ）。例如在 HTML 文件中加入 <META HTTP-RQUIV="Refresh" CONTENT=12> ，实际上就是 HTTP 头标告知浏览器每 12 秒更新一次文档。 　　　　　　　　　 优点：不需要服务器端配置 　　　　　　　　　 缺点

目前项目中的消息推送使用了DWR的Reverse Ajax，所以了解一下 Direct Web Remoting Reverse Ajax ( http://directwebremoting.org/dwr/documentation/reverse-ajax/index.html ) Index the ability to asynchronously send data from a web-server to a browser. DWR supports 3 methods of pushing the data from to the browser: Piggyback , Polling and Comet . By default DWR starts with active Reverse Ajax turned off, allowing only the piggyback transfer mechanism. Getting Started with Reverse Ajax 要使用Reverse Ajax，需要配置 WEB-INF/web.xml ： <!-- lang: xml --> <servlet> <servlet-name>dwr-invoker</servlet-name> <servlet-class>org

I am trying to pass an Int8Array, which is created from an array buffer to a java method via DWR, which accepts it as a byte[] parameter. Javascript : uploadFiles: function(eve) { var fileContent = null; for(var i = 0; i < this.filesToBeUploaded.length; i++){ var reader = new FileReader(); reader.onload = (function(fileToBeUploaded) { return function(e) { file = e.target.result; var view = new Int8Array(file); // fileContent object contains the content of the read file }; })(this.filesToBeUploaded[i]); reader.readAsArrayBuffer(this.filesToBeUploaded[i]); } } I want the contents of view to be

I have done a bit of testing on this myself (During the server side processing of a DWR Framework Ajax request handler to be exact) and it seems you CAN successfully manipulate cookies, but this goes against much that I have read on Ajax best practices and how browsers interpret the response from an XmlHttpRequest. Note I have tested on: IE 6 and 7 Firefox 2 and 3 Safari and in all cases standard cookie operations on the HttpServletResponse object during Ajax request handling were correctly interpreted by the browser, but I would like to know if it best practice to push the cookie manipulation