Hint and Tips for Working with DWR
This is a new list of things to look at to help you when working with DWR. Please add comments on the things that have helped you...
Creating a "Google Suggest" Component
I would strongly recommend not writing your own suggest component. It is quite simple to get something basic working, but very hard to get keyboard navigation working properly. Several libraries contain suggest components:
Script.aculo.us contains an Autocompleter.Local function which people have found to integrate with DWR. It's easier to get the 'Local' version working remotely with DWR than the 'Remote' version which has demands on how the server works. You may find this mail to the dwr-users mailing list helpful, or the blog entry by Rubens.
Alternatively Peter from Rimu Hosting went and implemented a self-contained and dwr-friendly version which he posted here.
Enhancing file uploads
Pierre Losson has written up a way to integrate DWR with Commons-FileUpload. It's well worth looking at. Full source and war demo are available.
Improve the loading message
The useLoadingMessage() function in DWR 1.0 has some flaws (like you can't customize the message and you need to be a bit careful when you call it) You can fix these flaws with some simple cut and paste of a new version of this function. The documentation for useLoadingMessage() has more details.
Use the server console
DWR does some fairly verbose error reporting, which can help a lot in working out what has gone wrong with your application. If there is anything wrong you should take careful note of messages when your container is starting and when the error happens. Generally errors will be output at the WARNING or ERROR levels, but reading INFO level messages might help too.
If you do get log message telling you something is wrong, but need to know more, make sure you can read INFO level messages because DWR sometimes outputs informational log messages with background information when something has gone wrong.
Use the debug/test pages
Another useful helper when something is broken is the debug/test pages (See http://localhost:8080/[YOUR-WEBAPP]/dwr). Basic use of these pages is covered in the getting started guide, but it's worth remembering when things are broken because sometimes these pages will give you more information about what is going wrong.
Accessing HttpServletRequest
You can access HttpServletRequest and associated objects.
Passing extra data to callbacks
It's common to need to pass extra information to a callback method, but since all callback methods have only one parameter (the return code from the remote method) this can be tricky. There is a whole page dedicated to helping you with this problem.
Tuning Server Performance
CPU bottlenecks: DWR has been looked at by some fairly serious performance gurus who told us that DWR was basically irrelevant to performance. Time spent inside DWR is swamped by the web server and by the network. If you really need to tighten things up then you should reduce logging to error and fatal levels only, but the main job will be looking at your own code.
Network bottlenecks: Starting with version 2.0 DWR manages cache lifetime so the browser does not read more data than it needs to. Previous versions of DWR may leave the browser assuming that it needs to re-read the DWR javascript more often than it really does.
There is a simple solution to this issue in version 1 - copy the JavaScript files into your web-app and refer to them from there so the webserver can do what it is good at. You could also consider merging all your JavaScript files into a single file and running the DOJO compressor on them to save more space.
The situation in DWR 2.0 is slightly more complex because engine.js is dynamically generated, so you should not include this file in any compression scheme when using 2.0. We hope to remove the need for the dynamic parts of engine.js in version 2.1 and to add an inline script compressor.
