JSF is a very powerful, component-based technology for developing
web applications. Not surprisingly, several software vendors have updated their toolkits to
support JSF, promising rapid development and ease of use through drag-and-drop
support when creating JSF-based web applications. However, developing
applications with JSF does have its drawbacks. One less-obvious one is
drag-and-drop support.
For years, Microsoft has evangelized the benefits of drag-and-drop support when
advertising their Visual Basic product; however, what the company's sales reps have
failed to share with their customers are the pitfalls when using drag-and-drop
functionality for creating applications—although it is quick and easy to build
applications using this functionality, the results are not very flexible or extensible.
For example, when you need to implement a technique that executes outside of
a component's event cycle, then the quick-and-easy approach to
building an application is not the way to go. Take the JSF-based database
browser shown in Figure 1. It has a simple interface that enables you to view data
within a database. All of the
components that present data are hard-wired to a backing
bean. If maintenance and update cycles are a non-issue, then this works quite
well. Most applications, however, require life-long maintenance changes with
ever-increasing demand for faster deployment. For the sample application in Figure 1, after a database query
has been executed the results need to be bound to visual components for display
purposes.
Figure 1. Sample application that queries a database
Drag-and-drop support has its benefits when developing applications with
components that remain static or rarely change, as is the case with the Rows
Per Page field in Figure 1. In this case, the combo box doesn't change, and
its contents are populated by a backing bean property that lists the number of
rows to be displayed per query. The only item that changes in this setup is the
internal list control, but not the form component.
Drag-and-Drop Drawbacks
To illustrate the drawback of drag-and-drop development, I created the
static JSF page shown in Figure 2. The data table used to assign values to the
columns (Name, Status and Oid) is populated by a hard-coded dataset. Although
this example demonstrates how easy it is to build a web page with JSF, any change
to an MVC model (should one be used) or user interface requires code changes,
re-testing, and redeployment—not an ideal solution in today's fast-paced production environment. Most importantly, the
display attributes such as column names and number of columns can't be known at
design time and thus the data displayed is concrete and only applicable to a
specific query or data table specified when designing a web page.
Figure 2. A simple, static JSF page
A Powerful Dynamic Mix
The solution to this static problem is using dynamic component generation—that is, creating components at runtime. In
order to generate your components dynamically, you must first consider the
final user interface layout. Most user interface components are containers that
may contain child components. One component that is well suited for adding
child components dynamically is the HtmlPanelGrid component. This component enables
you to add dynamic objects to statically placed component containers, which is
certainly simpler than positioning them on a page. To create a page entirely at
runtime is beyond the scope of this article, but not beyond the capability of
the framework discussed here.
Having the ability to create a data table and populate it with dynamic
content is very powerful. Even more powerful is the ability to add buttons and backing
event handlers for those dynamic components. Backing events are triggered when the user interacts with a component (such as a button) on the screen. When designing
static JSF pages, backing event handlers are generated by the IDE (for those that
support and implement JSF effectively), or created by the developer, when he or she
chooses a component that can trigger an event and wants to assign code to a specific
event for that component.
You might be thinking, "Great, I can create a button at runtime; so what. I
need to respond to the event for that button. How do I do that?" The answer is simple. I am not saying that Java classes
should handle such events dynamically, but rather
that you should have a source of actionable tasks that can support user-triggered events. In other words, you shouldn't have a dynamic interface approach that is so incomprehensible or
complicated that it is deemed questionable. Instead, the goal is to provide a means to
generate an interface dynamically, based on logic or flow, and have a
pre-defined list of supported event handlers to capture these events. To do this, the event handlers themselves
have to handle the data being acted upon. Dynamic class loading would also be a
possibility for linking dynamic component events to some code base unknown at
design time, but this has far-reaching and complex design and development implications and is beyond the scope of this
article.
By linking events from dynamically created buttons to event handlers, you
can create a more fully fledged application that supports dynamic navigation. Figure 3 shows an application with a tabbed panel component, which contains two
dynamic data grids (the Grid and Field tab containers house a data grid)
and the database configuration parameters (Config).
Figure 3. A simple tab interface
Page:
1
2
3
