gtuhl: startup IT and software development

I’ve talked about DWR before. It is a mature project that is well constructed and very useful. DWR generates Javascript files at runtime that you can include in your client-side code and use to call exposed Java methods. A few days ago I wanted to generate these files as part of our normal build process so that we could open and read them directly. More importantly (for me at least) I wanted to have them in my project directory so that IntelliJ could index them. This may seem trivial but I am obsessive about letting my IDE aware of as much as possible and I found this to be a huge help when writing client-side Javascript. Now I can ctrl-space complete, ctrl-click, and everything else IntelliJ can do with Javascript on these DWR Javascript files.

I posted my plan to the dwr mailing list and as usual the creator of DWR himself showed me exactly how to accomplish this when using a dwr.xml file for configuration and when not using Spring. If this is your environment I encourage you to search that list. There is a great community there and I have found it extremely helpful and responsive many times.

That said, I wanted to do this in our Spring project using DWR 2.0rc2 with an annotations based DWR configuration. It was pretty easy to take Joe’s example and adapt it to this case. Here is the core of the Java code to get started.

First the imports I am using:

import org.directwebremoting.util.FakeServletContext;
import org.directwebremoting.util.FakeServletConfig;
import org.directwebremoting.impl.ContainerUtil;
import org.directwebremoting.impl.DefaultContainer;
import org.directwebremoting.extend.Remoter;
import org.directwebremoting.spring.SpringContainer;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import javax.servlet.ServletContext;
import javax.servlet.ServletConfig;

Now the code that sets up a DWR Remoter object which we can request Javascript content from:

ClassPathXmlApplicationContext appCtx =
  new ClassPathXmlApplicationContext(”testContext.spring.xml”);

Map<String, String> initParameters = new HashMap<String, String>();
// comma-delimited list of annotated classes
initParameters.put(”classes”, “FooAjaxController”);
// telling DWR to use a different Container subclass
initParameters.put(”org.directwebremoting.Container”, 
  ”org.directwebremoting.spring.SpringContainer”);

ServletContext servletContext = new FakeServletContext();
ServletConfig servletConfig = new FakeServletConfig(”dwr-test”, 
  servletContext, initParameters);

DefaultContainer container = 
  ContainerUtil.createDefaultContainer(servletConfig);
((SpringContainer)container).setBeanFactory(appCtx);
ContainerUtil.setupDefaultContainer(container, servletConfig);
ContainerUtil.configureFromAnnotations(container);

Remoter remoter = (Remoter)container.getBean(Remoter.class.getName());

// do what you want with the Javascript content

appCtx.close();

In the above code, before the appCtx.close() line you can pull Javascript content out of the Remoter object like this:

remoter.generateInterfaceScript("fooAjaxController", "/fake/path");

The second parameter is the path you want the Javascript files to use for accessing corresponding Java servlets and in this case they didn’t matter. fooAjaxController is the Javascript name for the DWR Java class. My preference for naming of DWR classes is that all Java class names end with AjaxController and that the bean name and DWR Javascript name are the same and the camelcase version of the class name.

From here it is pretty straight forward to do whatever you want with this Javascript content from the remoter. In my case I pulled the bean definitions out of the Spring context, separated out all beans with a name ending in AjaxController and then built lists of bean names and class names at run-time to use for the classes parameter and for reading the content back and writing it out to files. This way nothing had to be hard-coded and changes made to the bean configurations in our Spring context were automatically accounted for.

Hopefully someone else finds this useful.