In this podcast, taken from Joe Walker's presentation on Ajax and Direct Web Remoting (DWR) at TSSJS Barcelona, the DWR author gives inside tips on using the Java open source library and leads a discussion on developing and using DWR and Ajax. Topics include:

• How to integrate DWR into your existing web applications, whatever your current codebase looks like
• How to avoid the common mistakes people make when writing a first Ajax application, and how to debug problems using the best available tools
• Several tricks you can use to make your website more responsive and easier to use along with looking at the available libraries to reduce the amount of code you need to write

Joe starts with DWR's own utility library and indicates some of the other tools that work well with DWR. Joe also spends some time looking at DWR's current features and where new features are being developed. View the slides for this presentation.

DWR does have some advantages, no doubt. But generating Ajax from business logic will tightly couple your presentation layer with your business logic. For 1 man project it does save a lot, but in real life it will make your life more complicated. In ideal world designer should be able to work on presentation even when you don’t have business logic implemented and developer should be able to work on business login without presentation layer. Of course in real world it is not easily achievable, but there are more elegant solutions. Most of our projects are loosely coupled, and it allows the designer to use his own tools when developer can work in his favourite IDE. That improves development time quite a bit. Would be nice to hear other opinions regarding DWR.

I've looked into DWR before, and I liked what I saw, conceptually and practically. It's nice to be able to hide the complexities of ajax requests and expose it in the OO fashion on the client side. I don't think it's necessarily tying your domain layer to your presentation layer. In reality, if you look at it as a service oriented architecture, your view layer (DWR), is making calls to your domain service layer interfaces. Though you can design your views without worrying about service side implementations. You can achieve the same with a pretty simple ajax library, but I think DWR is a good proxy interface to domain layer. Ilya

DWR does not ask you to alter your business logic, so I don't see that it is creating any ties. I regularly work by prototyping the business logic, creating a stub implementation in Javascript and then separating the Javascript/view development from the business logic generation. That seems like your ideal world to me. Joe. http://getahead.ltd.uk/dwr/ http://getahead.ltd.uk/blog/joe/

DWR does have some advantages, no doubt.

But generating Ajax from business logic will tightly couple your presentation layer with your business logic.

Not so. Used DWR and the XWork/WebWork libraries to write my own simple little Ajax-based MVC framework, basically regenerating snippets of pages rather than the whole thing. Was very simple to do, yet achieved everything that old-school MVC frameworks do (except they regenerate the whole page). Of course, the heavy lifting was already there in the form of XWork and DWR, what I did is just glue it together with a DWR-based controller and some generic javascript for the thing.. / Wille Buzzword Bingo

DWR does have some advantages, no doubt.

But generating Ajax from business logic will tightly couple your presentation layer with your business logic. For 1 man project it does save a lot, but in real life it will make your life more complicated.

In ideal world designer should be able to work on presentation even when you don’t have business logic implemented and developer should be able to work on business login without presentation layer.

Of course in real world it is not easily achievable, but there are more elegant solutions.

Most of our projects are loosely coupled, and it allows the designer to use his own tools when developer can work in his favourite IDE.
That improves development time quite a bit.

Would be nice to hear other opinions regarding DWR.

To chime in on what others have said, DWR lets you build an alternate View as opposed to "tighly couple your presentation layer with your business logic." I can see where you'd draw that conclusion, but if you are clever about how you expose functionality and/or your Model through DWR, your M and your C never know this AJAX-enabling V is even there.

The audio appears to start in the middle, at least not at the start. Also, the audio doesn't appears to be related to the slides. Jeff

Hi. I discovered DWR 1 month ago, tried using it in a demo project running on WebLogic 8.1, and liked its simplicity very much. But I quickly found a bug. I reported the bug (https://dwr.dev.java.net/issues/show_bug.cgi?id=114) and suggested a fix, but nothing has changed yet. The bug report is still marked as new, and has not been reviewed. How active is the development of DWR? Do you plan to fix the bugs, or are you working on the next version? On which appservers is it tested? JB.

I'm using DWR for project a month ago. It's pretty work well with spring and hibernate on any application server. good and easy configuration but only lack of support components like dojo.

DWR and dynamically table editing examples are good but, cell creation functions is not working well if you add the dynamic content as html text in each cell content function instead you have to add DOM tree objects/fragments to make it work. I am sure this is happening because I am overriding the default cellCreator function. Because given example was just using the default cellCreator function. I think this is very important to be aware of. Deha Peker