Developers wanting to leverage Ajax must often confront a tension between the desire to bring rich user interfaces to their applications, on the one hand, and the need to use well-tested enterprise development tools and frameworks, on the other. The tension exists because Ajax and traditional Web enterprise standards still stand apart not only in APIs and programming models, and also in the maturity of development tools used for each.

BEA recently teamed up with Ajax component vendor Backbase to mitigate that tension in the area of developers tools. Their current proof-of-concept uses JSF as a means to integrate Backbase's Ajax component framework into BEA's Eclipse-based IDE, Workshop. While the choice of JSF as the vehicle of integrating Ajax into an enterprise Java development tool implies several trade-offs, it also facilitates design-time support for Ajax components, which is an important productivity benefit.

Backbase's Jep Castelein, and BEA's senior marketing manager, Pieter Humphrey, talked to Artima about some of the trade-offs in using JSF, as well as about some of the benefits that result from this integration. Castelein explained that developers have been looking for more sophisticated Ajax development tools, but few existing tools provide the level of development experience available in enterprise Java IDEs:

The biggest challenge developing with Ajax today is how to integrate [Ajax] into the [development] workflow. If you just write a couple of lines of JavaScript code, that's great for small features, but for something more complex, you need to follow the correct architecture, and you need to follow a workflow, especially if you work with a team.

A common ... Ajax development workflow is that you develop something completely in JavaScript, outside your development environment, or with a tool specifically designed for JavaScript development. Then you try to look and see how to tie the JavaScript functionality into your server-side code—how the communication takes place, when communication is triggered, and what kind of communication is going to happen. In principle, these are two separate development processes. To bring these closer together, we believe that we need to plug [Ajax development] into an existing workflow, instead of creating a brand new [workflow]...

In the last few years, we've seen some interesting tools that ... help you develop Ajax-based applications in a Web-browser-based environment. What we've found, however, is that many developers prefer to use an IDE to develop Ajax applications. And in the Java world, that sort of IDE is often something based on Eclipse, including improved versions of the standard Eclipse IDE, such as BEA's Workshop.

A technical hurdle for better Ajax support in IDEs has been the lack of design-time support for Ajax components. JavaScript, CSS and DOM are evaluated dynamically in a runtime environment. While that's initially convenient, it also means that developers must actually execute their code inside the browser to see it work.

By contrast, design-time support in IDEs for Java code helps pinpoint coding errors prior to compilation and execution, possibly saving time in the development process. The integration between BEA Workshop and Backbase's Ajax components lends similar design-time support for working with Ajax components, explains BEA's Humphrey:

A unique piece of extension we do to Eclipse is AppXRay, which is functionality that analyzes your application at design-time the way a compiler would. It tries to eliminate runtime debugging by giving you almost compiler-level intelligence, even in the context of working with JSF, Struts, Hibernate, EJB 3, and even JSP and custom JSF... It creates a dependency database real-time, and scans your source code. As you type, it does validation against your current configuration of JSF, or your current configuration of Struts, or a custom JSP tag library. It gives you the ability to do code completion for extended components. If you reference something that does not exist in your current configuration, it will tell you. It also lets you visually inspect the dependencies, which is very useful when you inherit an application from another developer. You can grok the application a little faster that way...

If you start dragging and dropping visual components on the palette, you will get some level of wizard guiding you through code generation. As you're configuring things in a visual view, or as you're working within source view, you have the opportunity to set properties, and configure some basic component behavior, or stylesheet, or how a component will occupy an area of the screen.

Design-time support has long been a stronghold of Microsoft's Visual Basic component model, and has only recently found similar maturity in the Java world, mainly with tools centered around JSF. A formal design-time API for tool vendors has been proposed as JSR 276, Design-Time Metadata for JavaServerT Faces Components.

How do you currently work with Ajax elements in your enterprise Java projects? What tools and techniques have worked for you, and which ones haven't?