So what is Barracuda all about? What's the vision behind this project?

Jacob Kjome

Put simply, Barracuda is a presentation framework designed to make it easier to build web applications. Of course, most other presentation frameworks claim the same thing, so what makes Barracuda different? To answer that question we need to consider the big picture.

For Java developers, the Webapp paradigm became viable with the introduction of the Servlet API. At last there was a standard, high performance set of interfaces that made it relatively easy to build HTML applications. Of course, it didn't take long to figure out that embedding client-side markup within server-side Java code resulted in a maintenance nightmare.

In response to this--and in an effort to win ASP developers over to Java--Sun created JSP technology which effectively turned the tables: Instead of dealing primarily with Java code in servlets, developers could now focus on the design aspects of their applications and just embed java "scriptlets" commands into the markup. Sun has proclaimed JSPs as the future of Java on the server, and the industry as a whole has embraced this position.

Of course, many developers who actually use JSPs to build real applications have quickly come to the realization that this shift is not necessarily a panacea. In many cases, we simply end up with Java embedded inside HTML; from a maintenance perspective there's not much difference compared to simple servlets. A growing number of Java engineers have realized the need for better separation of code and content, and this has led to all manner of experimentation, particularly in the areas of flow-control and template engines.

Barracuda is different from other presentation frameworks in several ways.

First, we wanted to support a Model 2 architecture, an MVCish approach to webapps that supports application flow-control by separating "Controller" logic from the code that actually generates the "Views". Other presentation frameworks feature Model 2, but Barracuda goes a step further. We decided to expand the model to support true event-driven processing, an approach that has proven particularly useful in client-server development.

Second, we felt that one of the major problems with existing approaches was their failure to provide a real component model: with JSPs and other template engines, it's kind of an "all or nothing" proposition; for Barracuda, we wanted a generic component model that would allow for all kinds of components to be freely intermixed. So rather than creating a template engine, we created a template engine component. The developer is free to use it where it makes sense, or to use another component where it doesn't. This makes the whole thing incredibly extensible.

Third, we wanted to leverage the code-content separation provided by the XMLC approach to generating client UIs. With XMLC you never embed "programming logic" in the client markup the way most template engines do. Instead, you compile client templates into java classes that can be instantiated and then manipulated using the W3C DOM interfaces. This has proven a highly effective approach to parallel development: designers focus on markup; developers focus on coding.

The only real drawback to XMLC has been the complexity associated with the low-level DOM interfaces. To solve this problem we created a suite of prebuilt components that sport familiar, strongly-typed MVC interfaces like you'd find in Swing. Each of these components can be used to manipulate the DOM structure without ever needing to interact with the cumbersome DOM interfaces--the components do that for you. All the developer has to do is implement a simple Model interface to provide the data; the component takes care of all the gory rendering details.

Fourth, we wanted to make it easier to deal with HTTP forms. To do this we created a simple-yet-powerful forms model that allows the developer to map form elements to first class Java objects and validate them using resuable validators that can be "assembled" to support complex business validation logic.

Fifth, we wanted to make it easier to support localization. We were able to do this by automatically creating localized versions of the XMLC templates; all the developer has to do is provide standard property files for each desired locale. Then when loading DOM templates, the developer simply specifies the desired locale and the proper template will be loaded, in much the same way as Java's ResourceBundles work. The tedious aspects are completely encapsulated; localization becomes easy instead of onerous.

Finally, all of these framework subsystems--events, components, forms, and localization--can be used independantly. You can pick the pieces that make sense for your particular needs. Furthermore, each of the frameworks is fully pluggable, making it possible to replace the standard code with custom implementations should the need arise.

This provides a basic overview of the Barracuda distinctives. Currently, we have just released our 1.0 Final release, and a number of companies are already actively developing projects using the Barracuda presentation framework. Of course, there's still lots of work to do, and plenty of room for people to get involved.