Slashdot Mirror
DWR Makes Interportlet Messaging With AJAX Easy
An anonymous reader writes "You can use the sample code in this article as a starting point for developing your own applications; the code also shows how DWR extends the Java programming model to Web browsers. With DWR, it's almost as if JavaBeans were available in the browser. DWR simplifies your work by hiding almost all the details of Ajax and allows you to concentrate on the task at hand instead of the nuts and bolts of Ajax development."
I was worried I might not be able to easily let my interportlets message each other. They're so lonely!
Ajax uses a combination of XML, HTML, DHTML, JavaScript, and DOM.
Is it me, or does the scope of Ajax seem to be expanding?
"Interportlet"?
"'...allows you to concentrate on the task at hand instead of the nuts and bolts of Ajax development.'"
Last time I checked the "nuts and bolts" of AJAX was only a few dozen lines of code... all it is is sending a server request in the background.
It's missing the hyphen.
Inter-portlet communication
As in, communication between portlets.
Portlets are a specific type of J2EE application.
I didnt RTFM or TFS but WTF does DWR stand for?
Come as you are, do what you must, be who you will.
Google Gadget viruses.
7h3$3 4r3n'7 7h3 Ðr01Ð$ ¥0 4r3 £00|{1n9 f0r. M0v3 4£0n9. --OB1
Number of Megabytes required to run software * Maximum depth of class hierarchy * Number of lines of XML configuration = Enterprise!
Badass Resumes
Am I the only one who was wondering what exactly Design Within Reach had done to improve AJAX? I mean, sure, I really like some of their lamps, but I think that AJAX is beyond even their power to salvage.
Can we please drop JSP? writing java code within HTML is very very bad.
In the same line of thought, can we drop the millions of XML config files needed for this sort of stuff? they are not needed.
I am using Echo2 for intranet applications and it works fine. No HTML, no XML. Coding the GUI is exactly like Swing. But the problem is that every action in the client triggers a response from the server...if I could program Java classes and the bytecode was translated to javascript on the fly, then I could write normal Java apps which would be executed as javascript on the client, thus minimizing the client-server communication.
Javascript and the web browser are nothing more than a bad implementation of the the NeWS Window System anyway...with NeWS, one could write a sort of postscript-like program to be executed on the display server (i.e. client), thus limiting communication between client and server to the absolutely minimal stuff.
Since the browser is doing the XML evaluating, and since a smart browser is going to be doing something like XML evaluating all day long (especially if you actually send XHTML as application/xhtml+xml), the browser probably has a very fast C or assembly XML parser. It probably isn't being evaluated in JavaScript.
So I have two questions: Is the browser's XML parser faster than the browser's JavaScript parser? (Probably, but I want benchmarks.)
And, on the server side, you have the same issue -- is it faster to generate XML (with one of many XML parsers/generators) or to generate JSON (which is simpler, but you probably end up using something written in the language -- IE, a pure perl JSON generator, or pure PHP, whereas with XML you're calling a C generator from the Perl or PHP)?
The fact that JSON is physically smaller probably matters some, though not much if you're gzipping it anyway.
It's also entirely conceivable that some custom, simpler language than either JSON or XML could be developed, that parses faster in JavaScript than either XML or JSON do in the browser. I doubt it, but as long as you're benchmarking stuff...
Don't thank God, thank a doctor!
It's not the AJAX, it's the DHTML. And now that there's more interest in the DHTML and use of the DOM in JavaScript (all due to AJAX), people are actually trying to do cross-browser implementations, because Firefox is also getting much more popular -- you can no longer create a DHTML (or AJAX) site that works only in IE.
I mean, you're right, it's easier than it looks to someone who doesn't know how to do it, but it's harder than it looks to someone who does.
Don't thank God, thank a doctor!
This sounds exactly like the Google Web Toolkit ....
The revolution will not be televised. It won't be on a friggin blog either
This DMR *seems* cool at first, but the fact that I have to inline the Javascript code insid ethe JSP with this stupid cusotm tag kills it for me. JSP's are supposed to be the presentation layer *only* - if you have JS code it should be in external .js files as much as humanly possible. THis also helps download times a lot since the .js files can be cached.
Personally I think that JSON-RPC is far superior to this "DMR" stuff. It's also been around much longer, so it's tried and tested. It also has non-Java backend implementations.