Failed Experiences and Lessons from using DWR to reverse Ajax in the past week, I tried to use DWR's reverse Ajax function to develop a web-based page instant messaging system, but failed. The technical obstacle is that, apart from the current scriptsession, all other scriptsessions that have been obtained as much as possible seem to have been castrated, it is impossible to send messages and JavaScript code from the server to the client. It may be because the Ajax function of DWR is implemented by regular polling. If the browser of the client does not initiate a round robin, it is useless for the server to do anything else! In this way, point-to-point communication through HTML pages cannot be achieved. Only the web chat room applications provided by DWR can be implemented. Next, we will summarize the bugs and experiences of the browser and DWR's Ajax function reversal. I. IE is the worst-performing browser. Firefox is good for other browsers and has not been tried yet. 1. the Ajax function is reversed and can be correctly applied on Firefox. However, on IE, webpage receiving cannot be realized instantly. 2. IE is the most nonstandard browser. Dom implementation is not standardized. The standard DOM method is correctly displayed in Firefox, but it does not work in IE7. Of course, this is not a big problem, but there are still some ways to overcome the shortcomings of IE. Ii. DWR's Ajax function is reversed. In addition to the current scriptsession, all other scriptsessions that have been obtained by DWR seem to have been castrated, it is impossible to send messages and JavaScript code from the server to the client. 2. DWR framework
Dwrutil
ClassThe dwrutil class is a server-side proxy class that allows Java programmers to call the client's Java code. This class is actually a helper class. It actually uses the script field of scriptsession to send specific JavaScript code to the client. The existence of this class makes it easier for users to use some common functions. 3. The dwrutil and scriptsession classes lack the ability to distinguish which page of the browser to send JavaScript code. This causes serious problems. 1) without the ability to differentiate browsers, browser users cannot communicate point-to-point. 2) even if I get scriptsession, they also lose the ability to transmit JS Code to the client. 3) The page cannot be differentiated. In this way, the page with incorrect information transmitted by the server may occur. If the two pages do not have the same page element, an error indicating that the page element is missing is reported. If the two pages have the same elements, an error message is displayed. In short, there are still many shortcomings in DWR's Ajax function reversal! Iii. dwrdwr provides the function of remotely calling Java classes using Js. This is an RPC Remote Call mechanism. Remote method calls, such as RMI. Each published Java class automatically generates a corresponding JavaScript class. This JavaScript class is a local stub of the remote Java class and a proxy class. They simply call the corresponding methods of the Java class on the server through the XMLHTTPRequest object, and then return the results. DWR is a good news for a wide range of Java programmers. You don't have to learn and write complex javasript code and Ajax code. You only need to write Java classes and methods to complete most Ajax applications. On the other hand, remote rpc calls such as DWR have security issues, which are the same as other remote call mechanisms. Security mechanisms must be ensured before they can be used. DWR provides security mechanisms. However, I have not carefully looked at jdwr's remote call mechanism and need to adopt the same programming mode as other remote call mechanisms. That is, coarse-grained Java classes and methods should be released remotely, instead of fine-grained objects. Otherwise, serious performance problems may occur. For example, you should publish the class at the service layer of the business module, or the class at the service delegate layer of the performance layer. The data access layer class cannot be published. Those classes are fine-grained. Moreover, using the data federation method can perform crud operations on the database, which may cause serious security vulnerabilities. Remember that the DWR client is a browser. Anyone can write JS Code on their own machine, and then remotely access the released Java class. No security control is absolutely dangerous! I am only a bit familiar with the DWR framework. It seems that it is necessary to conduct in-depth and systematic learning and research on the DWR framework. Research and develop the Ajax function of DWR. If necessary, create such a function to reverse Ajax. For example, if you use a timer and regularly use ajax to asynchronously query the server, DWR may also implement the Ajax function in this way.
