DWR. xml configuration details

[Size = large] [/size] [align = center] [/align] My Chinese documents on dwr about dwr. xml makes a sorting, purely physical, and useful friends do not forget to stick to it, leave a contact information for communication and learning!

Dwr. xml is the configuration file of DWR. By default, it should be placed under the WEB-INF directory (web. xml directory)

Create a dwr. xml file
The structure of the dwr. xml file is as follows:

<! DOCTYPE dwr PUBLIC "-// GetAhead Limited // DTD Direct Web Remoting 1.0 //" http://www.getahead.ltd.uk/dwr/dwr10.dtd "> <dwr> <! -- Init is only needed if you are extending DWR --> <init> <creator id = "... "class = "... "/> <converter id = "... "class = "... "/> </init> <! -- Without allow, DWR isn't allowed to do anything --> <allow> <create creator = "... "javascript = "... "/> <convert converter = "... "match = "... "/> </allow> <! -- You may need to tell DWR about method signatures --> <signatures>... </signatures> </dwr> term
Here are some terms that must be understood-the parameter will be converted, and the remote Bean will be created. So if you have A bean named A and its method is called A. blah (B), you need A creator of A and A converter of B.

I. <allow>
Classes that can be created and converted by the trial DWR defined in the allow section.

Ii. Creators
The structure of the create element in the dwr. xml file is as follows:

<Allow> <create creator = "... "javascript = "... "scope = "... "> <param name = "... "value = "... "/> <auth method = "... "role = "... "/> <exclude method = "... "/> <include method = "... "/> </create>... </allow> most of the elements here are optional-what you really need to know is to specify a creator and a javascript name.

The creator attribute is required-it is used to specify the type of generator used.

By default, DWR1.1 has eight creators. They are:

New: creates an object with the new Keyword of Java.
None: it does not create an object. See the following reasons. (V1.1 +)
Scripted: creates an object through BSF using a scripting language, such as BeanShell or Groovy.
Spring: Access Bean through Spring framework.
Jsf: Use a JSF Bean. (V1.1 +)
Struts: Use the FormBean of Struts. (V1.1 +)
Pageflow: access the PageFlow of Beehive or Weblogic. (V1.1 +)


If you need to write your own generator, you must register it in the init part.

The javascript attribute is used to specify the name of the created object in the browser. You cannot use Javascript keywords.

The scope attribute is very similar to the scope in the servlet specification. It allows you to specify the bean's lifecycle. Options include "application", "session", "request", and "page ". These values should be quite familiar to Servlet and JSP developers.

The scope attribute is optional. The default value is "page ". Cookies are required if you want to use "session. The current DWR does not support ULR rewriting.

The param element is used to specify other parameters of the generator. Each constructor is different. For example, the "new" creator needs to know the object type to be created. Parameters of each generator can be found in their respective documents. Please refer to the above link.

The include and exclude elements allow the Creator to restrict access to methods in the class. You must specify either the include list or the exclude list. For the include list, the default access policy is "deny". For the exclude list, the default access policy is "allow ".

For example, to deny all methods except setWibble (), you should add the following content to dwr. xml.

<Create creator = "new" javascript = "Fred"> <param name = "class" value = "com. example. fred "/> <include method =" setWibble "/> </create> is visible by default for all methods of classes added to the create element.

The auth element allows you to specify a J2EE role for future access control checks:

<Create creator = "new" javascript = "Fred"> <param name = "class" value = "com. example. fred "/> <auth method =" setWibble "role =" admin "/> </create>
--------------------------------------------------------------------------------



The new generator has been declared by default in DWR: <creator id = "new" class = "uk. ltd. getahead. dwr. create. NewCreator"/>. You do not need to add this section in the dwr. xml file. It already exists in the DWR. xml file.

This creator creates an object instance through the default function of the class. There are some advantages of using the new generator:

Security: The shorter the event for objects created by DWR to survive, the fewer chance of errors with inconsistent values among multiple calls.
Low memory consumption: If your site has a large number of users, this generator can reduce VM memory overflow.
You can use the new generator to create a remote Bean call using the following method:

<Allow> <create creator = "new" javascript = "Blah"> <param name = "class" value = "java. util. date "/> </create>... </allow> the Code sets java. util. date is mapped to Javascript and named as Blah. Therefore, in Javascript, when you call Blah. toString (reply) is a new java. util. the Date is created by the default constructor, The toString () method is called, and the result data is returned to the reply method (in this example, date is in string format ).




--------------------------------------------------------------------------------



None' the Creator does not create any object-it assumes that you do not need to create an object. This may be true for two reasons.

The scope you are using may not be "page" (see the above), and you have already created this object in the scope before. In this case, you do not need to create another object.

Another case is that the method to be called is static and no object needs to be created. DWR checks whether the method is static before calling the creator.

In both cases of appeal, you still need the class parameter to tell DWR what the object type it operates on is.




--------------------------------------------------------------------------------



The scripted creator has already declared in DWR by default: <creator id = "script" class = "uk. ltd. getahead. dwr. create. ScriptedCreator"/>

This builder uses BSF to execute the script to get the Bean, for example:

<Allow>... <create creator = "script" javascript = "EmailValidator"> <param name = "language" value = "beanshell"/> <param name = "script"> import org. apache. commons. validator. emailValidator; return EmailValidator. getInstance (); </param> </create>... </allow> the script generator has the following parameters:

DWR version description
Language 1.0 script language, a string, such as 'beance'. (required)
Script 1.0: the script to be executed. (Required, unless the scriptPath parameter exists)
ScriptPath 1.1 indicates the path of the script file. (Required, unless the script parameter exists)
Reloadable 1.1 checks whether the changes to the script file are detected to reload (optional, true by default)
Class 1.0 creates an object type (optional). If DWR is not available, the type is obtained through the generator.


Theme to be understood
To use this generator, you need to put some auxiliary libraries under the WEB-INF/lib Folder: BSF jar package, you need to use the script language jar package.

When a class is created using a script and the scope is session or application, if your script changes, the classes in the session are different from those in the script. In this case, an error occurs. Although the web container does not need to be restarted, the user needs to log out (or clear the session in some way) and then log on.

When the clazz parameter is not empty and used to create a new instance, DWR simply calls the class. newInstance () method. This method is fine unless the script is using a parameter to create a class or calling a function to configure this class. Unfortunately, each request has to re-run the script and cause the above problems.




--------------------------------------------------------------------------------



Generator
Steps for DWR and Spring to work together
Make sure you are using the latest DWR version. The Spring builder has changed, so you 'd better check the latest version of DWR.
Check that you have viewed the content in the Start Guide.
Make sure that your Spring Bean runs well outside DWR.
Configure DWR and Spring to work together. (See the following)
View the demo page: http: // localhost: 8080/[YOUR-WEBAPP]/dwr and check whether spring Bean appears.
DWR has no runtime dependency on Spring, so if you do not use Spring, Spring support will not be affected.

The SpringCreator
This generator will search for the beans configured in spring and create them using Spring. If you are using Spring, it will be very useful.

You can create a remote Bean by using the following method:

<Allow>... <create creator = "spring" javascript = "Fred"> <param name = "beanName" value = "Shiela"/> </create> </allow> search for your Spring Configuration
You can search for configuration files in three ways:

ContextLoaderListener
The simplest way is to use org. springframework. web. context. ContextLoaderListener. You don't have to use all the Spring-MVC functions. You only need this Listener, so this is a good solution. You need to make the following configuration in WEB-INF/web. xml:

<Context-param> <param-name> contextConfigLocation </param-name> <param-value>/WEB-INF/classes/beans. xml </param-value> </context-param> <listener-class> org. springframework. web. context. the best document of ContextLoaderListener </listener-class> </listener> I can find is javadoc. If you know more, please let me know.

Rob Sanheim pointed out that there is also a document that can gain an in-depth understanding of ContextLoaderListener.

Use the location * Parameter
If you want to specify which beans to use in dwr. xml, you can use the location * parameter. You can specify any number of files as long as the parameters start with location and are unique. For example, location-1 and location-2. These locations are used as Spring ClassPathXmlApplicationContext parameters:

<Allow>... <create creator = "spring" javascript = "Fred"> <param name = "beanName" value = "Shiela"/> <param name = "location" value = "beans. xml "/> </create> </allow> directly sets BeanFactory
SpringCreator has a static method setOverrideBeanFactory (BeanFactory) to set BeanFactory directly through programming.

Configure DWR and Spring
Bram Smeets writes an interesting blog that teaches you to configure DWR to replace WEB-INF/web. xml with beans. xml.

I am also interested in how to specify dwr. xml in beans. xml, although it seems a little Spring infectious disease. Does anyone know how to implement it? Please join the email list and let us know.




--------------------------------------------------------------------------------



Integration
DWR includes two JSF extension points, one generator and one ServletFilter.

'Jsf 'creator
DWR1.1 has a trial version of JsfCreator. You can use the following in dwr. xml:

<Allow>... <create creator = "jsf" javascript = "ScriptName"> <param name = "managedBeanName" value = "beanName"/> <param name = "class" value = "your. class "/> </create>... </allow> This allows you to call ManagedBean through DWR.

The Servlet Filter
The DWR/Faces filter allows you to call beans in FacesContext without the JSF lifecycle.

To use JsfCreator, you should add the DWR/Faces filter to web. xml.

<Filter> <filter-name> DwrFacesFilter </filter-name> <filter-class> uk. ltd. getahead. dwr. servlet. facesExtensionFilter </filter-class> </filter> <filter-mapping> <filter-name> DwrFacesFilter </filter-name> <url-pattern>/dwr/* </url -pattern> </filter-mapping> these two must be placed on the web. xml is put together with other filters and filter-mapping.




--------------------------------------------------------------------------------



Integrate Struts
DWR can work with almost any Framework. This website (the official website of DWR) is a strong proof of this, because it uses DWR in Drupal (PHP.

There are two levels of integration between DWR and Struts. The most basic layer is to use two frameworks at the same time. This is very easy, but it is not allowed to share actions between DWR and Struts.

DWR can call any method, so there is no reason not to let you call Struts Action from DWR unless you do not want to use it like this. What is the content of ActionForm and how does DWR do when ActionForward is returned?

A better way is to refactor the Action you want to call and extract the Action Logic. DWR and your Action can call the same method at the same time.

The 'struts 'creator
A StrutsCreator is added to DWR1.1. You can use the following in dwr. xml:

<Allow>... <create creator = "struts" javascript = "ScriptName"> <param name = "formBean" value = "formBeanName"/> </create>... </allow> This allows you to call FormBean in DWR.

Start sequence
If you want to use StrutsCreator, you must ensure that Struts is initialized before DWR. You can set <load-on-startup> of Struts in web. xml to be lower than that of DWR.




--------------------------------------------------------------------------------



Pageflow creator

One generator in DWR can work with PageFlow in Weblogic or Beehive.

The 'pageflow' Creator
A PageFlowCreator is added to DWR1.1. You can use:

<Allow>... <create creator = "pageflow" javascript = "ScriptName"/>... </allow> use the static method
DWR checks whether the method is static before calling the creator. If so, the Creator will not be called. Obviously, this logic applies to all creators, although "null" creators are the easiest to configure. Applicable Singleton type
For the creation of Singleton classes, it is best to use BeanShell and BSF to instantiate objects. For more information, see 'scripted '.
I occasionally need some new creators. The most common one is an EjbCreator. A good place to discuss new creators is in the mail list. DWR and HttpSessionBindingListeners
Note that DWR1.x uses the same setAttribute () method to store created beans. That is to say, if the declaration cycle of a Bean in dwr. xml is set to session, DWR will execute session. setAttribute (yourBean) every time the bean method is called ). This does not seem to cause any harm, but if you want to use the servlet event mechanism, that is, the HttpSessionBindingListener interface is used, you will find that the valueBound and valueUnbound events occur during each call, instead of the bean creation and session expiration. DWR2 only calls setAttribute () when creating an object for the first time (). Iii. Converters
We must ensure that all parameters can be converted. Most types in JDK already have converters, but you need to switch your code to DWR. In general, a <convert...> definition is required for the JavaBean parameter. By default, the following types can be converted without being defined: all native types: boolean, int, double, etc.
Native object types such as Boolean and Integer
Java. lang. String
Java. util. Date and Date in SQL
Array composed of the above types
The preceding Collection types (Lists, Sets, Maps, Iterators, etc)
From DOM, XOM, JDOM, and DOM4J DOM objects (like Element and Document)
The following are examples of these converters.

Array Converter
Bean and Object Converters
Collection Converter
Enum Converter
DOM Objects
Hibernate Integration
Servlet Objects (HttpServletRequest, HttpSession, etc)
Basic Converter
The native type is String, and the converter for simple objects such as BigDecimal already exists. You do not need to define it in <allow> <convert> of dwr. xml. They are supported by default.

Supported types by default include: boolean, byte, short, int, long, float, double, char, java. lang. boolean, java. lang. byte, java. lang. short, java. lang. integer, java. lang. long, java. lang. float, java. lang. double, java. lang. character, java. math. bigInteger, java. math. bigDecimal and java. lang. string

Date Converter
The Date converter is responsible for the Date type in Javascript and the Date type in Java (java. util. date, java. SQL. date, java. SQL. times or java. SQL. timestamp. Like the basic converter, DateConverter is supported by default.

If you have a Javascript string (for example, "01 Jan 2010"), there are two ways to convert it to the Java Date type: use Date in javascript. parse () parses it into the Date type, and then transmits it to the Server using the DateConverter of DWR; or transmits it as a string to the Server, and then parses it using SimpleDateFormat (or similar) in Java.

Similarly, if you have a Java Date type and want to use it in HTML. You can use SimpleDateFormat to convert it to a string. You can also directly upload Date to Javascript and format it in Javascript. The first method is simpler. Even if your converter is wasted, this will also limit the display logic on the browser. In fact, the following methods are better, and some tools can help you, for example:

The Javascript Toolbox Date formatter
Web Developers Notes on Date formatting
Other Objects
In fact, it is easy to create your own converter. The Javadoc of the Converter interface contains information. In fact, this need rarely appears. Before writing your own Converter, check BeanConverter. It may be what you want.

Iv. <init>
The optional init part is used to declare the bean creation class and the bean conversion class. In most cases, you do not need to use them. If you need to define a new Creator [JavaDoc] and Converter [JavaDoc], you need to define them here. However, we recommend that you check whether DWR is supported.

The definition in the init section only tells the existence of the DWR extension classes and shows how to use them. They are not used yet. This method is similar to the import Statement in Java. Most classes need to be imported before use, but only the import statement does not indicate that this class has been used. Each creator and converter use the id attribute for later use.

V. <signatures>
DWR uses reflection to find out which type should be used during conversion. Sometimes the type information is not clear. You can write the method signature here to clarify the type.

The signatures section enables DWR to determine the Data Type stored in the collection. For example, in the following definition, we cannot know what type is stored in the list.

Public class Check {public void setLotteryResults (List nos) {...} the signatures section allows us to imply what type DWR should use for processing. The format is easy for anyone who understands the generic type of JDK 5.

<Signatures> <! [CDATA [import java. util. list; import com. example. check; Check. setLotteryResults (List <Integer> nos);]> </signatures> Another parser in DWR is dedicated for this purpose, so JDK1.3 DWR works even in your environment.

The parsing rules are basically the same as the expected rules (with two exceptions), so the types under java. lang will be imported by default.

The first is the parser bug in DWR1.0. in some environments, the correct type cannot be returned. So you don't need to worry about it.

The second is the "sunny day" Parser for this parser. That is to say, it is very loose and does not want the compiler to strictly ensure that you are correct. So sometimes it will allow you to lose the import:

<Signatures> <! [CDATA [import java. util. list; Check. setLotteryResults (List <Integer>);]> </signatures> A more formal parser will be used in future DWR versions. This compiler will be defined based on official Java, so you 'd better not use too much of this unstrict stuff.

The signatures section is only used to determine the type parameters in generic parameters. DWR determines the type by its own reflection mechanism or runtime type, or assumes it is a String type. Therefore:

Signatures is not required-no generic parameters:

Public void method (String p); public void method (String [] p); signatures-DWR cannot be determined through reflection:

Public void method (List <Date> p); public void method (Map <String, WibbleBean> p); correct guesses without signatures-DWR:

Public void method (List <String> p); public void method (Map <String, String> p); signatures-DWR is not required and can be determined by the runtime type:

Public List <Date> method (String p); there is no need to make keys of all objects in Javascript belong to the String type-you can use other types as keys. However, they will be converted to the String type before use. DWR1.x converts the key into a String using the Javascript feature. DWR2.0 may use the toString () method to perform this conversion in the service segment.

6. Multiple dwr. xml files
There can be multiple dwr. xml files (for details, see the web. xml document ). The definitions in each file are added together. DWR uses this function to load the basic configuration file. We can look at the standard configuration file to understand the content of dwr. xml.



The above resources from http://wiki.javascud.org/display/dwrcn/