Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×

DWR Makes Interportlet Messaging With AJAX Easy 39

Posted by Hemos from the hiding-it-all-away dept.
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."
This discussion has been archived. No new comments can be posted.

DWR Makes Interportlet Messaging With AJAX Easy More

DWR Makes Interportlet Messaging With AJAX Easy

Comments Filter:
  • 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? (Score:3, Informative)

      by Aladrin ( 926209 )
      Nope, it's always been all those. Remove any 1 of them and AJAX doesn't exist.
      • 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 du
        • 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.)
          • 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.

      • 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,
        • 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 faste

    • Re:Expanding? (Score:2, Informative)

      by ben there... ( 946946 )
      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? (Score:4, Informative)

      by mwvdlee ( 775178 ) on Monday July 17, 2006 @10:07AM (#15731471) Homepage
      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.
      • 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.
  • "Interportlet"?
    • 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!
    • New buzzword to BS VCs. Spiffy.
      • 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? (Score:3, Insightful)

      by Reverend528 ( 585549 )
      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.
      • 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.
        • 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? (Score:4, Insightful)

    by The MAZZTer ( 911996 ) <megazztNO@SPAMgmail.com> on Monday July 17, 2006 @10:17AM (#15731546) Homepage

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

    • 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.
    • 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.. (Score:2, Funny)

    by RalphSleigh ( 899929 )
    I didnt RTFM or TFS but WTF does DWR stand for?
    • 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

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

    • 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.
  • 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 n
    • 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.
  • This sounds exactly like the Google Web Toolkit [google.com] ....

    • 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 progra

  • Problems (Score:3, Insightful)

    by brunes69 ( 86786 ) <slashdot@keir[ ]ad.org ['ste' in gap]> on Tuesday July 18, 2006 @07:36AM (#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.

Slashdot Top Deals

GREAT MOMENTS IN HISTORY (#7): April 2, 1751 Issac Newton becomes discouraged when he falls up a flight of stairs.

Close