dwr官方文档

客户端

Client Side Documentation

The main documentation index has a more detailed list of topics available.

Client side documentation contents:

• Writing JavaScript with DWR
• Passing extra data to callbacks
• Browser Support
• engine.js
• util.js

服务器端：

Supported Environments

DWR requires JDK 1.5 or later. Older JDK's may be used with the aid of a byte code weaver such as Retroweaver.

DWR requires a servlet engine that supports servlet spec version 2.2 or later. Earlier versions of the servlet spec may also work.

It is frequently tested in many operating environments including:

• Tomcat
• Weblogic
• Websphere
• JBoss
• Jetty
• Resin
• Sun ONE
• Glassfish

JSF Integration

DWR contains 2 extension points for JSF, a creator and a ServletFilter. The JSF integration is not included in the dwr.jar. It is currently only available in the dwr-noncla.jar which is available for download.

The 'jsf' Creator

An experimental JsfCreator is included with the normal DWR download. You can use this from dwr.xml as follows:

<init>
  <creator id="jsf" class="org.directwebremoting.faces.JsfCreator"/>
</init>

<allow>
  ...
  <create creator="jsf" javascript="ScriptName">
    <param name="managedBeanName" value="beanName"/>
    <param name="class" value="your.class"/>
  </create>
  ...
</allow>

This will allow you to make calls into your ManagedBeans from DWR. Please note the init section. This section is required because the JSF creator is not defined in the standard dwr.xml (because of the non-cla issue).

The Servlet Filter

The DWR/Faces filter allows you to access beans from your FacesContext without being officially part of the JSF lifecycle.

In order to use the JsfCreator, you should add the DWR/Faces filter to your web.xml file.

<filter>
  <filter-name>DwrFacesFilter</filter-name>
  <filter-class>org.directwebremoting.faces.FacesExtensionFilter</filter-class>
</filter>

<filter-mapping>
  <filter-name>DwrFacesFilter</filter-name>
  <url-pattern>/dwr/*</url-pattern>
</filter-mapping>

The 2 elements will need to be placed alongside other filter and filter-mapping elements in your web.xml file.

This JSF integration was written by Pierpaolo Follia, with inspiration from an article from thoughtsabout.net.

DWR Java API

DWR has a deliberately small Java API. Usually, as a web application developer you will only need to depend on WebContext / WebContextFactory if you are using reverse ajax, you may in addition need ServerContext / ServerContextFactory. These classes are located in the org.directwebremoting package.

WebContext and ServerContext are your connection to other parts of DWR and the general servlet API. WebContext is used when you are in a DWR thread. It uses a ThreadLocal variable to connect you to the running container. ServerContext can be used outside of a DWR thread, but as a result you will need to pass it a ServletContext so it knows where DWR is running.

These classes give you to access to the standard HTTP servlet objects:

• HttpServletRequest
• HttpServletResponse
• HttpSession
• ServletContext
• ServletConfig

You use WebContext like this:

import org.directwebremoting.WebContext;
import org.directwebremoting.WebContextFactory;
///
WebContext ctx = WebContextFactory.get();
req = ctx.getHttpServletRequest();

It is important that you treat the HTTP request and response as read-only. While HTTP headers might get through OK, there is a good chance that some browsers will ignore them. Any attempt to change the HTTP body WILL cause DWR errors.

See also the JavaDoc for DWR in general, or the specific page for WebContext.

Alternative Method

It is possible to get access to the HTTP servlet objects without writing code that depends on DWR - just have the needed parameter (i.e. HttpServletRequest, HttpServletResponse, HttpSession, ServletContext or ServletConfig) declared on your method. DWR will not include it on the generated stub and upon a call of the method it will fill it in automagically.

For example if you have remoted a class like this:

public class Remote {
  public void method(int param, ServletContext cx, String s) { ... }
}

Then you will be able to access it from Javascript just as though the ServletContextparameter was not there:

Remote.method(42, "test", callback);

DWR will do the work of filling in the parameter for you.

There is one slight caveat with this method. You should ensure you are not using the 'callback function as first parameter' idiom, instead use the 'callback as last parameter' or 'callback in meta-data object' idioms. See the scripting introduction.