So what is Barracuda all about? What's the
vision behind this project?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.
You might want to check out our Todo List to get an idea where
things will be going from here. There's lots happening, so now is a great time to
get involved!
|