Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

DWR Makes Interportlet Messaging With AJAX Easy

Hemos posted more than 8 years ago | from the hiding-it-all-away dept.

39

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."

cancel ×

39 comments

Sorry! There are no comments related to the filter you selected.

Thank God... (0)

Anonymous Coward | more than 8 years ago | (#15731311)

I was worried I might not be able to easily let my interportlets message each other. They're so lonely!

Expanding? (1)

rowama (907743) | more than 8 years ago | (#15731339)

Ajax uses a combination of XML, HTML, DHTML, JavaScript, and DOM.

Is it me, or does the scope of Ajax seem to be expanding?

Re:Expanding? (2, Informative)

Aladrin (926209) | more than 8 years ago | (#15731426)

Nope, it's always been all those. Remove any 1 of them and AJAX doesn't exist.

Re:Expanding? (1)

rowama (907743) | more than 8 years ago | (#15731754)

Nice thing about /. is that one can learn something new. Before, I had the mistaken notion that Ajax was simply concerned with using XMLHttpRequest to avoid large HTTP transactions and page reloads. Now, I realize this has to involve DOM to make it useful. However, it does not require XML, or XHTML, to work. If you use JSON you can eliminate XML and still have Ajax (eventhough XML is implied in the name).

If you will kindly confirm this understanding of Ajax, I can safely store the new rule away in the dusty recesses of my mind.

Re:Expanding? (1)

Aladrin (926209) | more than 8 years ago | (#15732297)

Yes, technically you could send an xmlhttprequest without any xml. But since a large part of 'ajax' is the dynamic pages resulting from the request, you can't really do 'AJAX' without the XHTML, at the very least. (And for what little it's worth, XHTML is really just specific XML.)

Re:Expanding? (1)

LDoggg_ (659725) | more than 8 years ago | (#15732540)

you can't really do 'AJAX' without the XHTML

Why not?
You don't have to apply a stylesheet and convert to xhtml on the client. You can simply read the DOM and create HTML from javascript. Or you could just send preformatted html. Or you could use JSON as has been mentioned.

Re:Expanding? (1)

aztracker1 (702135) | more than 8 years ago | (#15732394)

Well, it's not XML, but you can do AJAX (at least the style) with JSON encoding rather than XML responses... JSON evaluates into JavaScript much faster than XML does, it is also, in general far smaller than XML is in regards to size.

The biggest issue with JSON over XML, is de-encoding in server-side platforms. I'm aware of a few server-side platforms that work in JavaScript but none, afaik are in wide use (outside of classic asp). Anthem uses JSON, not sure about Rails, and not sure what else uses it, but it is a great option when somewhat bandwidth constrained.

I want benchmarks. (1)

SanityInAnarchy (655584) | more than 8 years ago | (#15733632)

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...

Re:Expanding? (2, Informative)

ben there... (946946) | more than 8 years ago | (#15731445)

DHTML combines HTML, JS, DOM, and CSS.

XML is in many cases the best method of sending data to the AJAX script.

Both have been part of AJAX all along.

Re:Expanding? (3, Informative)

mwvdlee (775178) | more than 8 years ago | (#15731471)

It's you.

Basically, AJAX is a website that uses HTTPRequest.
The XML, HTML, DHTML, JavaScript and DOM are just logical extensions of that premise. Similarly you could say AJAX also uses TCP/IP and HTTP. Though, likewise, it says nothing.

Re:Expanding? (1)

complete loony (663508) | more than 8 years ago | (#15731814)

I had a little project that did just that. Using a java applet to multicast packets to all peers on an intranet site. Javascript, Java, DHTML, IE 4, and TCP/IP (plain html server side in this case). WAAAAAY before AJAX or even XMLHTTPRequest (I believe) was invented.

Re:Expanding? (0)

Anonymous Coward | more than 8 years ago | (#15748393)

It all falls down when the user or their settings disables javascript. None of it works. Totally unreliable.

What the hell? (1)

david.given (6740) | more than 8 years ago | (#15731404)

"Interportlet"?

Re:What the hell? (1)

no_barcode (840948) | more than 8 years ago | (#15731498)

A portlet is like a Java applet, except it's built specifically as a little program that runs inside a web portal. There are some very rigid rules it must follow to be considered a portlet. It's like a plug-in.

I've found that if you have a problem with your portlet, you can plug it up with your Ajax and prevent any sort of embarrassing leaks. Ajax has amazing absorption, and it's very comfortable because it's designed with portlets in mind. So it feels like you're not even wearing an Ajax. It's great!

Re:What the hell? (0)

Anonymous Coward | more than 8 years ago | (#15731501)

I'm not sure what it is, but I think it's got something to do with Chloe from 24 and self-defending Cisco firewalls.

Re:Inter-portlet (0)

Anonymous Coward | more than 8 years ago | (#15731552)

It's missing the hyphen.

Inter-portlet communication
As in, communication between portlets.

Portlets are a specific type of J2EE application.

Re:What the hell? (1)

jo42 (227475) | more than 8 years ago | (#15731675)

New buzzword to BS VCs. Spiffy.

Re:What the hell? (1)

Manitcor (218753) | more than 8 years ago | (#15731757)

hardly a buzz word and hardly new: http://en.wikipedia.org/wiki/Portlet [wikipedia.org]

other names that have been used in the past are:
gadget
web part
pagelet

An industry group of the major enterprise portal companies got together and worked on standarizing some things like what to name those little "sub pages". This is also the same group that brought you the JSR-168 specification and to some extent WSRP.

Re:What the hell? (2, Insightful)

Reverend528 (585549) | more than 8 years ago | (#15731870)

Clearly you've never read the JSR-168 spec [jcp.org] or you'd know that portlets are little web applications that adhere to standards so crippling that the easiest way to communicate between two portlets on the same server is to utilize the clients' web browser in a convoluted AJAX hack.

Re:What the hell? (1)

aztracker1 (702135) | more than 8 years ago | (#15732410)

Honestly, this is probably going to be marked as a troll. But it sounds like a pretty typical java based solution to me... Don't get me wrong, I like java, but every web/http/html implimentation (not browser applets) I've seen or worked with makes me sick to my stomach.

Complexisity is more enterprisey (0, Flamebait)

Reverend528 (585549) | more than 8 years ago | (#15732743)

True, java solutions seem confusing and misengineered when you look at them up close, but if you take a step back you'll realize that the usability and maintainability isn't lost, but has been traded for a vast quantity of enterprise. If you don't believe me, just perform these simple calculations to see how much enterprise your software is worth:

Number of Megabytes required to run software * Maximum depth of class hierarchy * Number of lines of XML configuration = Enterprise!

Nuts and bolts? (3, Insightful)

The MAZZTer (911996) | more than 8 years ago | (#15731546)

"'...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.

Re:Nuts and bolts? (1)

dnebin (594347) | more than 8 years ago | (#15733137)

The request send/retrieve may only be a few dozen lines, but the dom handling and data marshalling on both sides typically exceeds that line count.

The DOM is what will kill you... (1)

SanityInAnarchy (655584) | more than 8 years ago | (#15733645)

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.

DWR.. (2, Funny)

RalphSleigh (899929) | more than 8 years ago | (#15731739)

I didnt RTFM or TFS but WTF does DWR stand for?

Re:DWR.. (1)

cyranoVR (518628) | more than 8 years ago | (#15732686)

DWR - Direct Web Remoting

It can be pretty much summed up as "RMI-like functionality implemented with JavaScript." Having used DWR, I'm not really sure if it uses XMLHttpRequest or something else, because the library abstracts that from the application developer. The server-side can code POJOs and the client-side can code against JavaScript functions. The DWR servlet and configuration file are the "glue" that gets the client-side to the server-side objects.

The limitation I've bumped up against is that the DWR servlet expects all remoting requests to come in via a serlvet mapping of /your_context/dwr/*, which makes is difficult to work with existing web applications that application parameters embedded in the URL path. This can be overcome by implementing a pluggable interface, but it's enough to make me look at using ad-hoc JSON generated from jsp pages instead...

Interportlet Messaging Is A Euphamism For... (1)

Doomedsnowball (921841) | more than 8 years ago | (#15731854)

Google Gadget viruses.

Design Within Reach? (1)

Onan (25162) | more than 8 years ago | (#15733112)


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.

Re:Design Within Reach? (1)

dnebin (594347) | more than 8 years ago | (#15733158)

DWR = Direct Web Remoting in this situation. DWR is a tool for marshalling java beans from the servlet side into javascript objects on the client side whilst taking care of the AJAX request/response cycle, etc. Using DWR to it's fullest you don't need to write a line of servlet/javascript code for the communication.

Please, drop JSP and XML config files... (1)

master_p (608214) | more than 8 years ago | (#15733224)

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.

Re:Please, drop JSP and XML config files... (0)

Anonymous Coward | more than 8 years ago | (#15733466)

writing java code within HTML is very very bad.
Actually, its saved me a lot of time in the past.

Re:Please, drop JSP and XML config files... (0)

Anonymous Coward | more than 8 years ago | (#15736695)

mixing (X)HTML and and any kind script code in the *same file* with processing directives
like <?, <% etc breaks encapsulation and introspection into your codebase, costing you
time and scaleability in the long run. half the reason "web 1.0" "failed"...
keep the presentation layer and business logic seperate if you don't want to make an
unmaintainable mess. In fact how doing it in such a crippled way can be said to "save time"
is beyond me! it's more that a serious lack of application server tools forced such an
incoherent methodology on us ten years ago, and sad to say but that antipattern is now
firmly entrenched in the industry by people who "know best" and don't want to know better...

okay just ranting there...

Re:Please, drop JSP and XML config files... (0)

Anonymous Coward | more than 8 years ago | (#15733470)

>>Can we please drop JSP? writing java code within HTML is very very bad.

Guess that means no more PHP or ASP either?

Re:Please, drop JSP and XML config files... (0)

Anonymous Coward | more than 8 years ago | (#15733788)

GWT

Re:Please, drop JSP and XML config files... (1)

aevans (933829) | more than 8 years ago | (#15734508)

There's a reason why every computer has a browser but none of them have java GUIs. And it isn't Microsoft. If people wanted Swing apps they'd have them, whether Microsoft provided them or not. People aren't that loyal to the OS. But people wanted a browser, and Microsoft was force to develop one to compete. Microsoft dropped their JRE because no one wanted it.

Re:Please, drop JSP and XML config files... (0)

Anonymous Coward | more than 8 years ago | (#15738706)

Can we please drop JSP? writing java code within HTML is very very bad.

Well yeah, that's why 8 years ago jsp taglibs came out. Get with the program.

This sounds like (1)

Joff_NZ (309034) | more than 8 years ago | (#15734054)

This sounds exactly like the Google Web Toolkit [google.com] ....

Re:This sounds like (1)

kap1 (164828) | more than 8 years ago | (#15737325)

Actually, DWR exposes POJO's on the server via Javascript peers in the client.

GWT, on the other hand, is really two things in one: first, it compiles Java code to Javascript, much like javac converts Java to bytecode; big portions of java.lang and java.util are available to the developer. Second, it allows you to execute and debug your code in a JVM. The idea is that the code in the JVM will behave exactly like the compiled Javascript code in the browser.

I think the point of GWT is that good Java programmers are easy to find whereas good Javascript/CSS/XHTML programmers are hard to find. This way they can write Java and produce Javascript. For more on GWT, see here [pathf.com] .

Problems (2, Insightful)

brunes69 (86786) | more than 8 years ago | (#15735720)

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 [metaparadigm.com] 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.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?