DWR comes as a simple jar file and a few lines to add to your web.xml file to configure the remoted classes. In a web page you add a couple of <script> tags to indicate which classes you wish to import and can then call your Java code directly from Javascript. More detailed instructions are available on the DWR site.

The Javascript works by dynamically creating an iframe through which it calls the DWR servlet with instructions about what Java code to call. The DWR servlet marshalls the parameters, calls the server-side Java code and returns the reply to the iframe, which triggers an onload, which returns the reply to the calling Javascript.

Direct Web Remoting home page

Editorial Note: These days we are seeing more use of the XML HTTP Request object

Anybody have a demo site of this project in action? I'm a big fan of the JavaScript driven XML/RPC or SOAP interface to reduce bandwidth usage, and to improve the user response/experience. Last time I tried to build it out, I had such a hassle with IE that I finally tossed it out, but perhaps this project would help to cover all of that? So, any demos of this?

Isn't this quite similar to JSRS ???

I just used the Google bit on Firefox 1.0 and it worked beautifully. Joe, I also looked over some of your website. You bring up the caveat to keep in mind security concerns when using your project. I was hoping you might expand on that a little bit. We could use this to access a java class to retrieve data from a database table or a session bean to access data from a database table: what would the security concerns be and which would be a better choice from your product's view? Also, we were thinking about accessing a web service through a method call in our java with your product (so we could simply display the retrieved info without submitting), any experience with this? Sorry if these questions seem simplistic to folks, but you make the implementation of your product so simple, we thought you'd probably want some of us less experienced folk to use it as well.

You just need to think for a while about the class you are exposing and check that it's methods are all ones you really want to expose.
If you were to randomly add classes without thinking about what methods you were exposing then you could discover that you'd given access to more functionallity than you meant to.
That's what the warning was about - I'm a bit paranoid about security so I wanted to get my caveats in early!

This is an important feature to build Rich Internet Applications and we use it for most of our enterprise applications for flicker free UI.

It is heartening to see that others are also thinking on similar lines.

We call them DataIslandServices where we identify UI components in the HTML and use IFrames to populate the only a portion of the Page without refreshing the complete page.

Gives a strong statement to our clients who say (using a thick client application is so much more easier because i donot have to see a complete page refresh).

Sarath.

Hi All, I have got to make reverse ajax work with DWR using Jetty with Continuations server.The code work fines in FireFox/1.5.0.2 but there are issues in IE 6.0 of the Jetty's long XMLHttpRequest being breaking out in between and the changes made in data at the server side being getting lost. Does anyone has an idea how to Disable Native XMLHttpRequest in IE 6.0 as I feel that it is creating problems???? To be specific I am writing a Javascript object from the server side to the client side by finding the script session and giving the Javascript function name at the server side.

http://www.google.com/webhp?complete=1&hl=en

It rocks.

http://www.google.com/webhp?complete=1&hl=enIt rocks.

For a while.
As I am concerned about cross browser compatibility I do not trust JScript for anything but simple things because JS works differently in different browsers and its behavior may change quite suddenly as browser patches get issued and applied.

Well, it's not the JavaScript that is the problem it's the browser implementations. So far they have not been very compatible, so I understand your comment. Anyway I was talking about 'Google Suggests' when I said it rocks.

Well, it's not the JavaScript that is the problem it's the browser implementations.

So far they have not been very compatible, so I understand your comment. Anyway I was talking about 'Google Suggests' when I said it rocks.

I understand.
Google suggest does not work in Konqueror,popup looks corrupted in my Firefox on Windows, and there is no guarantee that it will work after some patch.
I cannot call it rock solid.

(Although the idea is nice and it looks good in IE and Opera)

Google suggest is still a beta, so it is understandable that it is not "rock solid".
Such a feature is a nice to have, but it should (and probably will) degrade gracefully for browsers that do not support XmlHttp.
Give them time.

Firefox 1.0 on XP. Works like a champ.

Firefox 1.0 on XP. Works like a champ.

Actually, corrupted look that I mentioned caused by the way Jscript handles HTML rendering. Try customizing XP theme by changing fonts and screen DPI then you will see how Jscript popups and menus look like :).
 
While it has nothing to do with remoting itself such visualization problem does not add confidence in the client side Jscript.

popup looks corrupted in my Firefox on Windows,

What wersion of Firefox are you using ?
It looks ok in 1.0 ...

As I am concerned about cross browser compatibility I do not trust JScript for anything but simple things because JS works differently in different browsers and its behavior may change quite suddenly as browser patches get issued and applied.

MSIE 6.0 is available for 3 years already, so each and everyone on Windows platform must use this latest version if they want to use browse modern websites. Firefox 1.0 is released this November for most popular platforms, it is compatible and it is free, so there should not be problem here as well. When 20 years ago when they had started to sell cars with catalythic converters, it was commonly accepted that these cars take only unleaded fuel. How software is different?

These days we are seeing more use of the XML HTTP Request object.
As in : Google sugest
It gives you suggestions while typing. Some kind of completion. It seems to work with a service called by an XMLHttpRequest javascript object. Not sure if it is the most usefull example but it is rather impressive.
One can imagine using this solution for adress completion: give me your post post and I give you a list of towns.

I found some problems with XMLHTTPRequest object on Mozilla, but works so well on IE. Any one knows of making it work on mozilla.

Google Search uses "IFRAME" to call remote server instead of XML Httprequest object. PLS check google's JS file.

I am using XML-RPC libraries (www.xmlrpc.org) for connecting Javascript at Client side with Java at Server side, and it works very fine.

Which is the advantage of using DWR?

Thanks!
Ignacio.

I am using XML-RPC libraries (www.xmlrpc.org) for connecting Javascript at Client side with Java at Server side, and it works very fine. Which is the advantage of using DWR?

I'm not an XML-RPC expert but there would seem to be 2 benefits. Fisrtly the Javascript is much easier, from the examples the following Javascript: "Date.hashCode(reply0); " calls the hashCode method on a java.util.Date object and returns the answer to the reply0 method.

Secondly DWR is small a lean, so it is very quick. I doubt that you could get to Google suggest speeds with XML-RPC, but maybe you have a chance with DWR.

I've used http://jsolait.net/examples/xmlrpc/ and loved it. It felt like client-server programming in a web environment, which was great and worked nicely for me. If SVG would really catch on, this could be the final RIA solution: SVG 1.2 + Script + Browser...

Regards,
Henrique Steckelberg

we tried to use an xml-rpc solution too, the only problem was that we had to support older browsers. We ended up using a solution based on Bob Lee's livescript (http://crazybob.org/index.jsp) which allowed similar functionality even on old browsers.

The only disadvantage of this method is that you are limited by how much information you can send because it uses cookies. However, you can make several simultaneous requests which helps to get around that problem.

Also, we didn't test on low-bandwidth lines, I'm not sure how well it would work on 56k lines.

I gave this a quick spin, but I noticed that a bean's parent public methods aren't exposed? Is this done on purpose, or am I missing something?

Javascript is flaky. Its functionality depends on the version of browser, type of browser, security settings ( allows pop up etc.), etc. etc. Not to mention that debugging and maintaining javascript is extremely painful

If you need a rich client -- used JDNC or Java applet. YOu have a controlled rendering environment and the code is easier to read.

Javascript is flaky. Its functionality depends on the version of browser, type of browser, security settings ( allows pop up etc.), etc. etc. Not to mention that debugging and maintaining javascript is extremely painfulIf you need a rich client -- used JDNC or Java applet. YOu have a controlled rendering environment and the code is easier to read.

Agreed.
Applets would be a preferable solution if they were truly supported by JavaWebStart and if a central repository of 3rd party libraries was available to prevent clients from downloading the same libraries all over again!

My client is living through the hell of maintaining java applets that make http requests (in the background of the webapp). The mystery browser lock-ups, wait times, Sun vs MS JVM, etc, is not fun. We are recommending that they replace the applet "back door communication" with something lighter like HTTPRequest in JS. Google Suggest is inspiring.

My client is living through the hell of maintaining java applets that make http requests (in the background of the webapp). The mystery browser lock-ups, wait times, Sun vs MS JVM, etc, is not fun. We are recommending that they replace the applet "back door communication" with something lighter like HTTPRequest in JS. Google Suggest is inspiring.

What are they using now for "back door" communication. I've used HTTPRequest with applets and applications successfully for years.

And Sun vs MS JVM? Just say no to MS JVM. No matter how good it might have been - it is time to bury it.

My client is living through the hell of maintaining java applets that make http requests (in the background of the webapp). The mystery browser lock-ups, wait times, Sun vs MS JVM, etc, is not fun. We are recommending that they replace the applet "back door communication" with something lighter like HTTPRequest in JS. Google Suggest is inspiring.

This sounds more like a poorly coded applet.

MS vs. Sun JVM -- say no to MS JVM -- use applets that run in Sun's Java plugin.

Well, It is a Yes! Use Applet if you like it! I have developed a light <5k applet to communicate with server and call its functions from javascript. This solution is working on various systems. If I face problem, I just install java plugin (1.3.1_07) and the applet works fine! Adil

... and if a central repository of 3rd party libraries was available to prevent clients from downloading the same libraries all over again!

Sounds a bit like dll hell. Good idea, not so good when it is actually implemented.

Javascript is flaky. Its functionality depends on the version of browser, type of browser, security settings ( allows pop up etc.), etc. etc. Not to mention that debugging and maintaining javascript is extremely painful

Javascript is NOT flaky. All browser Javascript engines I knew are working identically. The case is that DOM implementations differ in various browsers, so decision to build thick cross-browser client based on default browser capabilities is unwise. This is doable, but it is a real pain.
If you are bound to the specific browser (which is often for intranet web applications), rich functionality based on Javascript works well though

Somehow that reminds me of "windows GUI programming is so different from the X Windows programming"
 
Anybody else who gets the feeling that the software industry moves in circles ;-)

Somehow that reminds me of "windows GUI programming is so different from the X Windows programming"&nbsp;Anybody else who gets the feeling that the software industry moves in circles ;-)

I would say its movement is a spiral, but I am not quite sure about direction along Z-axis… seems to be going south :)

From the website:

The best way to get started is to nick the code from the demo pages

What demo pages?

From the website: The best way to get started is to nick the code from the demo pages
<br/>
What demo pages?

I was referring to the pages in the previous steps - the advantage of that is that it is customized to your circumstances.

However I'm working on getting a live demo working.

Wow, I must say "this is really cool!". It is what I am looking for. It is best suited for web sites that have progress bar, tree based component, dynamic user interative feature..It helps us ease the pain of javascript stuff.

Thank you for great tool, Joe!

Regards,

Thang

Would this work with an <object/> instead of <iframe/>, since iframe has been deprecated?

There is a product which is from as far as I can see based on the same idea: Casabac (www.casabac.com). We use them to create web based applications that have a feeling like rich client applications. On the frontend side this is done by a lot of JS, which communicates over a hidden frame with Java based adapter logic. Still, we don't have to care about it, since Casabac handles all the JS<->Java adapter stuff and we can focus on writing the adapters. After struggeling a lot with all the web frameworks around we found this to be a real booth in development speed - at least when it comes to intranet applications. And the users like things like context menus and non-flickering pages in a browser based application.

Klaus

This looks like a nifty piece of technology (implementation and concept).

You could have your client side validation logic actually done on the server (instead of writing JS validation + server side validation, duplicating logic).

Your application could then degrade gracefully i.e. if JS is on and the version is supported, the bells and whistles can be used (seach suggestion ala google suggest, client side validation, pre-population etc).

If JS is off or not supported, application runs like a normal web app w/ server side validation etc.

Sure this one rocks! I've been finding a solution like this for some time now.

Thanks