DWR 2.0 milestone 1 does 'reverse Ajax'

Discussions

News: DWR 2.0 milestone 1 does 'reverse Ajax'

  1. DWR 2.0 milestone 1 does 'reverse Ajax' (24 messages)

    The DWR project has released version 2.0 milestone 1:

    This is probably the biggest release we've done in terms of new features:

    Reverse Ajax: DWR 1.x allowed you to asynchronously call Java code from Javascript. DWR 2.0 builds on this to allow you to asynchronously call Javascript code from Java. Reverse Ajax makes writing interactive applications much easier. The detailed release notes have more details and there is a chat example in the war file download.

    Cross-Domain Ajax: We now allow script tag remoting to enable cross-domain Ajax. This is in addition to XMLHttpRequest and iframe remoting.

    Automatic signatures Element: If you are using DWR 2.0 with JDK5 generics then you can skip the signatures element in dwr.xml. DWR can now work out the correct mapping all for itself.

    DWRUtil Updates: The biggest change is to allow template style DOM manipulation. Using cloneNode() you can create a repeated HTML structure from an array of Javascript data.

    Other new features: See the release notes for details of the refactoring to the org.directwebremoting package, new script scope for creators and attributes, and the new call meta-data abilities.

    For more information see the detailed release notes, or go straight to the download area.

    We've got an aggressive list of new features to add to DWR for the upcoming milestones. What would you like us to add?

    Threaded Messages (24)

  2. Reverse Ajax in a cluster[ Go to top ]

    Does this work in a cluster?

    For example, my requests are being handeled by server A, and I want to send a message to someone whos requests are being handled by server B. Is this kind of use case going to be supported by DWR2?
  3. Reverse Ajax in a cluster[ Go to top ]

    Astute question Travis,

    There could be some issues, but I don't think they are unsurmountable. We have the concept of a Script Session that is like an HttpSession but keyed on a unique number in some Javascript rather than a unique number in a cookie.

    The good news is that this means we can keep state without cookies, but it also means the state isn't automatically persisted across a clustered http session.

    There is nothing to stop us storing the script session data within an http session, thus giving you clustering but requiring cookies however you had that requirement already - so no loss there.

    Something to add to the list.

    Joe.
  4. Reverse Ajax in a cluster[ Go to top ]

    I think that depends on the server, since the server (i. e. Tomcat) handles the sessiones when they are in cluster. If I am wrong pleace tell me. -

    Alexis Quirós - Argentina
    =========================
    (aquiros at cubika dot com)
    (alexisquiros at gmail dot com)
  5. Do you have any update for JSF support in the 2.0? The "detailed release notes" do not mention it.
    The on-side documentation says only about experimental JsfCreator.

    --
    Sergey : jsfTutorials.net
  6. JSF work[ Go to top ]

    There is always something you forget to add!

    Yes we've added the ability to use value binding expressions - join the mailing list to find out more: http://getahead.ltd.uk/dwr/support

    Joe.
  7. Cross-Domain Ajax[ Go to top ]

    Cross-Domain Ajax: We now allow script tag remoting to enable cross-domain Ajax. This is in addition to XMLHttpRequest and iframe remoting.

    Is there an example somewhere of how this works? Thanks.

    -James
  8. Cross-Domain Ajax[ Go to top ]

    Cross-Domain Ajax: We now allow script tag remoting to enable cross-domain Ajax. This is in addition to XMLHttpRequest and iframe remoting.
    Is there an example somewhere of how this works? Thanks.-James

    I've just had a quick scan of http://ajaxpatterns.org/ expecting to see a good explanation, but there wasn't one.

    In essence you use DOM manipulation to add a <script ... tag to a page. The browser reads in the script (which is dynamically generated by DWR) and executes it.
  9. Cross-Domain Ajax[ Go to top ]

    Cross-Domain Ajax: We now allow script tag remoting to enable cross-domain Ajax. This is in addition to XMLHttpRequest and iframe remoting.
    Is there an example somewhere of how this works? Thanks.-James
    I've just had a quick scan of http://ajaxpatterns.org/ expecting to see a good explanation, but there wasn't one.In essence you use DOM manipulation to add a <script ... tag to a page. The browser reads in the script (which is dynamically generated by DWR) and executes it.

    Forgive my ignorance, but what does that have to do with cross domain Ajax? I don't see how dynamicly adding a script block to a page enables any sort of cross domain request. Thanks.
  10. Cross-Domain Ajax[ Go to top ]

    Found this: http://blogs.ebusiness-apps.com/dave/?p=92
    It is a way to go over the same-domain problem...now i understand what managing script tag means..

    John
  11. Cross-Domain Ajax[ Go to top ]

    Cross-Domain Ajax: We now allow script tag remoting to enable cross-domain Ajax. This is in addition to XMLHttpRequest and iframe remoting.
    Is there an example somewhere of how this works? Thanks.-James
    I've just had a quick scan of http://ajaxpatterns.org/ expecting to see a good explanation, but there wasn't one.In essence you use DOM manipulation to add a <script ... tag to a page. The browser reads in the script (which is dynamically generated by DWR) and executes it.
    Forgive my ignorance, but what does that have to do with cross domain Ajax? I don't see how dynamicly adding a script block to a page enables any sort of cross domain request. Thanks.

    The closest to an explanation on http://ajaxpatterns.org is the entry on "On-Demand JavaScript" : http://ajaxpatterns.org/On-Demand_Javascript. That entry acknowledges that "you can bypass the standard 'same-domain' policy that normally necessitates a Cross-Domain Proxy".

    Jason Levitt's "Fixing AJAX: XMLHttpRequest Considered Harmful" also walks through this solution (though he chooses to include an application proxy as well as a dynamic script tag) : http://www.xml.com/pub/a/2005/11/09/fixing-ajax-xmlhttprequest-considered-harmful.html
  12. Cross-Domain DWR[ Go to top ]

    Has anyone been able to solve the cross domain problem using DRW? If so do you have a working example?
  13. I have recently been looking at DWR. It looks great. It's just that currently our AJAX-Java module has been created using JSON-RPC-Java.

    How does DWR compare to JSON-RPC-Java (apart from being a more concise acronym)?

    Is it worth the investment in changing over, and if so why?

    One last thing, reverse AJAX... very cool.

    Damian
  14. Some differences:

    DWR does not use JSON. JSON can't do recurrsive objects and it isn't portable anyway - JSON-RPC-Java can't interact with all other JSON-RPC servers. I don't think you'd get Reverse Ajax working with JSON very easily either.

    I think DWR is probably easier to get started with than JSON-RPC-Java, but I'd be interested to hear what experiences you have on that.

    DWR comes with integration into a very large number of other libraries and frameworks - Spring, Struts, JSF, Rife, WebWorks, Hibernate, and virtually every XML library under the sun.

    I think JSON-RPC-Java encourages (mandates?) a synchronous development style, which I believe is the wrong way to go given Javascripts thread model.

    I'm sure there must be some points the other way. What are they?
  15. Tapestry support[ Go to top ]

    DWR comes with integration into a very large number of other libraries and frameworks - Spring, Struts, JSF, Rife, WebWorks, Hibernate, and virtually every XML library under the sun.

    Does DWR support Tapestry?
    Regards,

    E
  16. Tapestry support[ Go to top ]

    ... that would be great. I hope there will be support soon.
    This whole ajax stuff starts to get interisting for me.

    Kunstbilder-Galerie
  17. Tapestry support[ Go to top ]

    ... that would be great. I hope there will be support soon.This whole ajax stuff starts to get interisting for me.Kunstbilder-Galerie

    Tapestry has Tacos for Ajax support - I've not played with Tacos much, though. Is it missing features?

    Should I tackle Howard about it?

    Joe.
  18. Tapestry and JSF are server-heavy HTML processing and page generation frameworks.

    DWR is a data access layer, and uses DHTML pages that aren't typically dynamically generated, or only minimally dynamically generated.

    Why do people keep asking about "support" for their framework? You can query the java objects exposed in DWR as data service object directly assuming its in the JVM, or use a host of enterprise stuff to access them remotely, without using DWR.

    It shouldn't be DWR's responsiblity to support all these legacy, and I do mean legacy, server-heavy web frameworks. If the framework authors can leverage DWR, say in the Tapestry UI components or whatever, it's their responsibility. To add that stuff to DWR would just be API pollution, especially from the standpoint of frameworks that are so fundamentally different in approach than DWR.

    It's almost like LISP programmers demanding inline LISP evaluation merged into the next JVM and JDK release.
  19. Yeah-- sure. Please attend our JavaOne talk (TS-1161) this year and you'll see how incomplete your perception of DWR/RPC is for development.
  20. Some differences:DWR does not use JSON. JSON can't do recurrsive objects and it isn't portable anyway - JSON-RPC-Java can't interact with all other JSON-RPC servers. I don't think you'd get Reverse Ajax working with JSON very easily either.I think DWR is probably easier to get started with than JSON-RPC-Java, but I'd be interested to hear what experiences you have on that.DWR comes with integration into a very large number of other libraries and frameworks - Spring, Struts, JSF, Rife, WebWorks, Hibernate, and virtually every XML library under the sun.I think JSON-RPC-Java encourages (mandates?) a synchronous development style, which I believe is the wrong way to go given Javascripts thread model.I'm sure there must be some points the other way. What are they?

    In our current project we use JSON to serialize object graphs to the client (and back again). I think it works pretty well, and I have found it to be definitely less "fiddly" than the XML/XPath-on-the-client approach. You're correct about the difficulties with recursive object graphs - however this is fixed relatively easily by modifying the relevant JSON serializer implementation. We incidentally use DWR in conjunction with this system to call back to Java services.
  21. is DWR the dominant Ajax FW now?[ Go to top ]

    ?

    .V
  22. Great release[ Go to top ]

    Just wanted to say that this is a great release. I integrated it with RIFE yesterday and the code to do so was much less than before. DWR is really moving in the right direction.
  23. Need a new server ?[ Go to top ]

    Your site is slower than the horse I backed in last weeks national (and that's still running!)
  24. Reverse Ajax: DWR 1.x allowed you to asynchronously call Java code from Javascript. DWR 2.0 builds on this to allow you to asynchronously call Javascript code from Java.

    Looks like, instead of onreadystatechange of XHR set to some static javascript function/callback at the browser/client side, the server code would dynamically set a javascript function and pass it onto the stream.

    But, can the server invoke the Javascript function multiple times as part of the response, without polling?

    Thanks,
    Ravi Chamarthy.
  25. 'Reverse Ajax' = marketecture[ Go to top ]

    Good question Ravi. There is no such thing as 'Reverse AJAX'.

    Joe is on to something, but it's more marketing than technology. As I'm sure you already know, AJAX, or, more specifically, xmlhttprequest, is a client-side technology that allows the browser to contact the server asynchronously. There is no such functionality that allows the server to contact the client asynchronously.

    However, you can setup a polling mechanism that polls the server for content update (javascript, html, xsl, etc.) that can then be rendered via JS on the user's page.

    A simple example is Live Comments -- a really, really dumb application, but one where I show just how simple this technique is (see www.gmail.net).

    -janders