by Christian Cryder, Barracuda ArchitectNOTE: This article is part 1 of a 4-part series originally published in
the Lutris Developers Journal.
By now, many of you have probably heard of the Barracuda
project. Judging by the volume of email I'm getting, however, I suspect that a lot of
you would like to know more: What is Barracuda? Where is it going? How can I use it? How
can I get involved?
The article will be the first in a four-part series aimed at providing an introduction
to the Barracuda Presentation Framework. In this installment, we'll start with a high
level overview of the Barracuda roadmap.
Not Just Another Presentation Framework
We should probably start with the obvious: what is a "presentation
framework"? In its simplest sense, we can define it as any library or toolkit that
tries to make life easier for the developer, especially in terms of building the UI--or
"presentation"--portions of a web application. This particular domain is often
referred to as the presentation layer, and it has proven particularly difficult to
abstract because of the tight coupling between server code and client content, combined
with the connectionless nature of HTTP.
If you have done any amount of web development, you probably have first hand experience
with some of these problems: build an application using pure servlets and you quickly
encounter the difficulties of embedding client markup (HTML, WML, etc) within your Java
code; try using JSP and you soon experience the maintenance nightmare that comes from
putting programming logic (Java, scripting code) within your markup. Of these problems are
exacerbated by constant user demands for more functionality (which usually translates into
greater programming complexity).
Of course there are a number of presentation frameworks already out there. We've spent
a lot of time Surveying
the Landscape to evaluate the various approaches. Unfortunately, most offer only
incremental improvements on the development process because they fail to address the
underlying limitations of the approaches upon which they build. Struts, for instance,
takes a very JSP centric approach; if you are committed to that technology, its great
because it makes the pain a little more bearable. It does little, however, to resolve the
fundamental architectural problems. Approaches like Turbine suffer similar
limitations--the framework is useful if you are willing to adopt their approach and live
with the implications.
What's So Special About Barracuda?
While Enhydra's XMLC technology goes a long way
towards improving code/content separation, building and maintaining web-apps is still a
complex process: the developer has to deal with the low level DOM APIs; localization is
still a fairly manual process; mapping to and from HTTP form data is cumbersome; there is
no real server-side event mechanism. All this means there is still lots of room for
improvement.
With Barracuda we wanted to take a step back and re-evaluate how we build web
applications. In particular, we spent a lot of time looking at approaches that have proven
effective in other domains (like stated, client-server paradigms), and then asked how we
could apply these constructs to the web-app paradigm. We came up with a number of key
distinctives that will allow us to build on the XMLC value proposition while opening up
new and interesting possibilities.
Components on the Server
First and foremost, we realized that component technology has acted as a tremendous
enabler in the client-server development arena.
The advantages are obvious. Components provide a high-level abstraction so that
developers rarely have to deal with low-level rendering issues: you set a value in the
component and it takes care of actually painting it into the UI. Even more importantly,
component technology allows us to assemble more complex components from relatively simple
building blocks. In addition, component frameworks like Swing have demonstrated the value
of Model-View-Controller (MVC) patterns in application development. Using MVC, we can
populate very complex component structures by implementing a simple "Model"
interface.
In light of all this, we thought "Hmm...wouldn't it be nice if we could manipulate
XMLC generated DOM structures using an MVC Component interface instead of the low-level
DOM APIs?" This is precisely the type of functionality that Barracuda provides.
Developers familiar with Java Swing will find the Barracuda component model very familiar.
There are some notable enhancements, however, to accomodate the web-app paradigm.
First, the Barracuda component model supports pluggable renderers to support mutiple
types of client UIs (HTML, WML, XML, etc). If a developer needs to create a UI for a new
type of markup, all he needs to do is implement a handful of classes to tell the
components how to render themselves for the new UI. The components themselves do not need
to be modified!
Second, while many Swing developers will quickly recognize Barracuda's BList and BTable
components, the Barracuda component model allows us to create non-traditional components
as well. One example of this is the BTemplate, which acts as a mini-template engine on
whatever portions of the DOM to which we bind it. It is even possible to create components
which are completely non-visual!
Finally, the component framework also integrates with the Barracuda event model,
allowing a developer to add listeners to a component (ie. a Button) and receive
notification when an action occurs (even though the action actually takes place on the
client-side representation of that component). This makes event handling very simple for
the developer; the details--capturing the event on the client and routing it to the
appropriate listener on server--are completely transparent.
In the future, Barracuda will also support client-side scripting through a complete
library of Javascript components.
Server-side Event Model
As alluded to above, Barracuda provides a powerful server-side event model that allows
us to be notified when actions occur on the client. It does much more than just this,
however. The Barracuda event model provides a full fledged Model
2 event dispatching mechanism.
Model 2 is a term coined by the J2EE Blueprints; rather than
just processing an HTTP Request and generating a response directly, we instead handle the
request in two distinct phases. First, we validate the request, perform any business layer
processing, etc (this corresponds to the Control phase). Then we redirect the program flow
to the appropriate rendering logic (this corresponds to the View phase). This approach
allows for better decomposition of programming tasks.
While many presentation frameworks offer Model 2 functionality, Barracuda actually
converts the requests into true Event objects. In addition, the framework allows event
handlers to fire additional events. This makes it possible to use true event-driven
programming techniques on the server side.
XMLC Localization Enhancements
When working with web-apps, developers typically have two basic approaches to
localization: either maintain multiple copies of client templates, OR, set all localized
text dynamically for every request. The first approach is burdensome to maintain; the
latter approach has significant performance implications.
Barracuda makes the localization process easier by automatically creating localized
versions of the XMLC templates. All the developer has to to is provide property files for
all desired locales. Barracuda takes care of the rest at compile time. Barracuda also
provides a custom DOM loader class that will load the appropriate template based on a
specified Java Locale object.
This makes the whole localization process much simpler for the developer while avoiding
the maintenance/performance implications of the other approaches.
Form Mapping & Validation
The form mapping and validation package is designed to make it easier to work with HTML
forms. It accomplishes this goal by allowing you to specify which elements a form should
contain and how they should be mapped and validated. This allows the form mapping and
validation framework to do most of the dirty work for you. When you receive an
HttpServletRequest, you simply say "given the form specifications I have defined,
map/validate this request". Once the form has been mapped, you can easily access
elements in the form as first class Java object (ie. String, Boolean, etc). If an
element in the form is not valid, you'll be notified of the error.
The Tacklebox Approach
One of the best things about Barracuda is its recognition that different developers
develop differently. Put simply, not all developers are going to need all aspects of a
given framework. While many presentation frameworks force you into an "all or
nothing" kind of approach, Barracuda is designed to be used like a tacklebox--you
decide which lures make sense and then use those.
By design, we've tried to minimize dependencies so that each of the key features
described above can be used on its own. You only want localization? No problem. Want to
use the component stuff but not the event handling? No sweat. What if you'd
like to integrate components with something like JDOM, instead of XMLC? Yep, you can do
that too. The key is flexibility, and we've tried very hard to build that into the
framework from the ground up.
Getting More Information
In the next issue, we'll start diving a little deeper by taking a look at the
Localization framework. In the meantime, you can learn more about Barracuda by checking
out the website at http://barracuda.enhydra.org.
There's already a lot of online documentation and tutorials, and you can always get help
on the Barracuda mailing list. |