The Leading IDE for Web App Development

Aptana Journal

Subscribe to Aptana Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Aptana Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Aptana Authors: Yakov Fain, Kevin Hakman, Pat Romanski, Alan Williamson, Maureen O'Gara

Related Topics: Aptana Journal

Aptana: RSS Feed Item

DWR + Aptana Jaxer

I've been working with the guys from Aptana for the past week or so on adapting DWR to be a remoting layer for Jaxer.

jaxer page flow

Jaxer is a way to run JavaScript on the server. But it's not just JavaScript as an alternative to Java/Ruby/PHP/etc. Jaxer is Mozilla, on the server, with it's face ripped off and replaced by a snorkel to serialize the DOM to a web browser. John has a great introduction, or there's the podcast that Ajaxian did.

The vision with DWR was always to say: We've got Javascript in the browser, and Java on the server - lets connect them in the best possible way. This leads to the migration of view logic from the server to the client. But it's not safe to move it all; Validation is part of view logic, but that needs to be done on the server. With Jaxer you can specify scripts to be runat="server" or runat="both" to allow validation or other logic to be run in both places.

Some of the changes that we've made to DWR will only help you if you are using DWR inside Jaxer, but others could be generally useful.

There are 2 basic changes. DWR on the Internet needs to make sure that the Internet only touches the code that you want it to touch. DWR in Jaxer doesn't have this problem because it's not accessible from the Internet, so we can do away with almost all configuration. Secondly latency inside a server-room is tiny compared with the net, which makes synchronous XHR viable.

So as it stands at the moment in development, you can use DWR inside Jaxer like this (clearly this is subject to change):

<script type='text/javascript' runat="server">
Jaxer.dwr.pathToDwrServlet = "http://localhost:8080/demoServer/dwr";
Jaxer.dwr.require("util", "new/org.example.Demo");

function loadServer() {
  var data = Demo.getData();
  dwr.util.setValue('fillFromServer', data);
}
</script>

There are a number of benefits that come out of this even if you're not using Jaxer:

  • In dwr.xml you needed to specify javascript='ScriptName'. If (as is common) ScriptName == Class.getShortName then you can just drop the attribute, it will default properly.
  • Cross domain remoting is now automatically detected, and scriptTag remoting is used if needed.
  • There is a new init-param 'useAbsolutePaths' which might help people with trouble remapping DWR's location.
  • All URLs are now reconfigurable.
  • If you are using DWR in synchronous mode (which I don't recommend on the Internet) then you can use returned data in the normal way without needing a callback.

Read the original blog entry...