eBook: Guide to Storage Networking
eBook: Storage Networking 2, Configuration and Planning
Whitepaper: Storage Management Costs in the Enterprise: A Comparison of Mid-Range Array Solutions
Whitepaper: Virtualization - It's Not Just for Enterprises Anymore
Whitepaper: Continuous Real-time Data Protection and Disaster Recovery
No doubt the name at least is familiar: JavaServer Faces has been
talked about a lot, and much anticipated, with good reason. For years
there have been an ever-expanding choice of ways to take your web
application's output and get it on a page (or on some other kind of
display). The Servlet API did a lot to enable the first Java web
applications - having created web applications
for Java before Servlets, I can attest to
how much it helped! The first web applications
with Servlets cranked out HTML directly -
pretty much everyone now agrees this was a bad plan, and hard to
maintain to boot. Next came toolkits such as Apache's Element
Construction Set that generated the HTML for you. A step in the right
direction, but not far enough for most. Then came JSP: A hybrid, in
some ways, between an HTML page and a Servlet.
JSP was a significant step forward from Servlet-generated HTML - If
you use it right (and that's a critical if), you can enforce a pretty
clean separation of view and application logic. Better still, JSP's,
particularly once tag libraries came along, were simple enough that
non-programmers could help with the page layout process, particularly
for HTML formatting.
Other UI technologies went in different directions, though:
Apache's Velocity, similar and to some degree a successor to the
popular WebMacro project, applied a simple but extensible template
language to generating the UI portion of an application, reading
JavaBean properties from the Servlet
context (where the application logic put it). Tea, Maverick,
WebWork2, Scope, Echo, FreeMarker, Barracuda, Cocoon - all took
different, and in some cases radically different, approaches to
getting the data from the application logic to the page.
Sometimes, as in the case of Barracuda, Cocoon, and several
others, XML was involved, and potentially XSL transformations. Many
of these frameworks also delved into the application logic side of
the equation, proving much more than a UI system. Struts is perhaps
the most widely known example, taking the JSP approach to a new level
with a powerful custom tag library, and popularizing the concept and
advantages of Model/View/Controller that Smalltalk old-timers were so
familiar with. Over time, many common elements began to emerge
between such frameworks, and it became clearer what the best
practices were for UI technology in a web environment, what worked
and what didn't. Developers realized that web applications
that used HTML/HTTP as the basis of their UI were quite different
animals from desktop or "thick" client applications using
Swing or other such toolkits. The user, however, still wanted a rich
and responsive UI experience. There was still a wide gap in the way
the various frameworks produced the display from the data produced
from the application logic, and techniques and UI elements created
for one technology were not portable to the next. You couldn't take a
custom JSP tag from Struts and use it in an application build with
Scope, for example. You couldn't take UI components for Echo and
easily apply them to an application built with Cocoon. This meant
that anyone attempting to build tools to make it easier for page/UI
designers to do their job had to back one horse, or write many
different tools, neither of which was a very attractive option. As a
result, Java and J2EE lacked the rich graphical tools to help build
applications by comparison to an up-and-coming rival, .NET. While the
hard-boiled "vi" crowd didn't see this as a problem, it did
limit the adoption of Java and of many of these different frameworks
in many organizations, where experienced developer resources were not
available for creating Luis. Either the UI
got short shrift - the results of which we can see on the web today
in the many horrifying anti-examples of usability out there - or the
development project went wildly over budget re-inventing the wheel,
because there was no standard wheel to do UI development. The other
choice was to commit to a single UI framework approach, and abandon
any possibility of portability later on.
JSF should change all that - one of it's goals is to bring a
single common standard that tool-creators can use to build their
tools against, while still allowing many different options for
rendering the finished UI. One JSF-based design tool should be able
to be used on many different JSF implementations, and components
should be portable from one implementation to the next, so that neat
UI gizmo you built for one application
really can be re-used on another.
Sounds great - but where's the beef? How is JSF going to
accomplish these admittedly lofty goals? Let's look at JSF from
several different perspectives, and talk about about where the rubber
meets the road - how you'll be able to apply JSF from a practical
perspective on your development projects, no matter what UI
technology you're currently backing.
It's important to realize that JSF is not tied
inextricably to JSP, even though the reference implementation
demonstrates JSF with JSP. JSF defines non-visual UI components,
which sounds like a contradiction in terms
- the idea, however, is to separate the
definition of a UI component from it's presentation.
Much like dividing up UI and application logic, but at a finer level.
Now we're talking about dividing up the UI into a non-visual
representation and a rendering - a translation of that
non-visual representation into an actual display. That rendering can
be done in any number of ways, as we will see.
Add www.developer.com to your favorites Add www.developer.com to your browser search box IE 7 | Firefox 2.0 | Firefox 1.5.xReceive news via our XML/RSS feed
eKit: Essential HP Solutions for Your Data Center
IE 7
Firefox 2.0
