$URL: svn+ssh://christianc@svn.forge.objectweb.org/svnroot/barracudamvc/Barracuda2/trunk/WEB-INF/src_docs/architecture/vision.html $ - $Revision: 125 $
The Barracuda Vision
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 reusable 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!
$Date: 2006-01-02 15:59:13 -0500 (Mon, 02 Jan 2006) $