|
JDesktop Network Components
by Amy Fowler
June 22, 2004
|
More For Less
Over the years, we have consistently heard feedback about
building desktop clients for the Java™ platform ("Java
clients") that can be summed up in just one word: simplify.
Skilled developers have been able to create all kinds of
rich, responsive applications with the Java platform, however
developers with less time to invest are often thwarted by
the size and complexity of the interfaces they need to master.
This situation is not peculiar to the Java platform; all
of the platforms that provide comprehensive support for
building desktop applications — such as GNOME, KDE,
and Mac OS X — are necessarily complicated. However,
what some of them have, and what the Java platform lacks,
is a shortcut for developers who are building applications
that match a small number of common archetypes. Database
and web service front ends, forms-based workflow applications,
and simple chart/graph information visualization clients
are good examples of these common archetypes.
Thus, we have initiated a new open source project on javadesktop.org,
JDesktop Network Components
(JDNC), which aims to provide the shortcuts required
to construct these sorts of desktop applications in significantly
less time by reducing the learning, design, and coding
requirements. Additionally, JDNC has a specific
goal to make these shortcuts accessible to a broader
developer base. This ambition has led us to develop
a high-level XML markup language for JDNC that makes the
richness of the Java client platform, previously accessible
primarily to developers comfortable with the Java language,
amenable to markup developers as well! The goal to make
Java desktop client development accessible to a wider audience
is also driving our focus to make JDNC a natural companion
for development tools, which is a critical requirement.
This article provides an overview of the problem space
and technology, and closes with our plea that you get involved
to help shape it:
Data-Centric, Enterprise Desktop
Clients
Although applications rarely fit neatly into a cookie-cutter
mold, we've found that many of the applications which enterprise
developers need to build share a common cross-section of
functionality. In developing JDNC, we are creating shortcuts
for these common features so that developers can get applications
up very quickly and then easily enhance them over time.
Central to these "shortcuts" is a suite of
very high level user-interface (UI) components which
leverage Swing, but provide common functionality in a simpler
JavaBeans™ component API. Although these
components are indeed the project's namesake, they are only
part of the solution.
The most central feature shared by what we call "data-centric,
enterprise desktop clients" is connecting users
with data — loading it, viewing it, filtering
it, editing it, validating it, saving it, and so on. And
these days that data is usually tied to a network data source,
such as an SQL database, HTTP servlet, or WebService, bringing
with it the complexity of networking. JDNC does the heavy
lifting here, by providing built-in support for dealing
with these network data sources, including multithreaded
support (so the UI doesn't block during network operations)
and incremental loading — hence, the "Network"
in "JDesktop Network Components".
The application model for a data-centric enterprise client
boils down to the life cycle of its data. JDNC promotes
this notion by supporting the pattern of clearly separating
the data from the UI, but making it very easy to bind the
two together. Application data is encapsulated in
one or more client-side, UI-independent data models, such
as a JDBC RowSet or a JavaBeans component. The data-model
interface should be easy to understand and easily configurable
from tools, with simple properties to configure its data
source, metadata, edit constraints, validation logic, etc.,
and simple actions for common operations such as load, insert,
modify, cache locally (for off-line use), and update (back
to server). The UI components are then bound to that local
data model (or models) with a simple syntax. From a tool
the binding might be created by drawing a line between graphical
representations of the two objects. The connection between
the UI and the local data model is handled by JDNC's binding
mechanism, which automatically handles input validation,
type conversion, pushing and pulling values to/from the
model, and reporting errors to the user. This frees the
developer to focus on their data and how it should be presented
in the UI, rather than on the plumbing which glues the two
together.
And once a Java client, running on a memory/CPU-rich machine,
has its hold on that local data model, there is all the
power offered by the rich UI components and Java 2D™
API in viewing, manipulating, and editing that data,
usually without any additional round trips to the
server.
As JDNC is a work in progress, we have not
yet implemented all the functionality required to realize
this vision. For example, support for disconnected RowSets
(JSR 114)
will be included in the release following 0.5. However,
0.5 does include an experimental version of a data-binding
framework for Swing components which, being central to our
purpose, should evolve substantially over the course of
the project. You can view JDNC's
Feature Summary for detailed information about current
and planned features.
JDNC's Layered Approach
As we were coding JDNC, we quickly realized that if we
carefully layered the technology, we could offer simplification
not only to enterprise desktop client developers, but to
Swing programmers in general. Many of the features we were
building into the large-grained components (table sorting
and filtering, forms and data binding, etc.) are also quite
useful to someone who's using Swing's flexibility to construct
a custom client which might not fit one of JDNC's target
archetypes. Thus, we've carved JDNC into three distinct
layers, as shown as the colored boxes in the image below:
While the upper layers have dependencies on the lower layers,
you may choose to use JDNC at the layer which best fits
your needs and skill set. If you're a Swing developer looking
for a richer table component, then you might choose to use
only the Swing Extensions. If you're
a developer familiar with the Java language but not the
Swing API, then you should find that the higher level JDNC
API simplifies your effort in constructing a basic Java
UI. And if you prefer the declarative style of XML, then
the JDNC markup language is the
place to start. Let's peek at these layers from bottom to
top.
Swing Extensions
The Swing Extensions package includes extensions to the
Swing API for the common features required by JDNC. These
APIs have been designed to be congruous with Swing and can
be used in any Swing application, but the components are
lower level than the components in the JDNC
API layer. Some of these features may be candidates
for a future J2SE release. Below are some of the key packages
currently in this project:
| Swing Extensions Package |
Description |
org.jdesktop.swing |
Contains API and extended Swing components
which provide common functionality required by data-centric,
enterprise client applications, such as JXTable,
JTreeTable. |
org.jdesktop.swing.actions |
Contains classes related to the JDNC actions
framework. |
org.jdesktop.swing.binding |
Contains API which enables
Swing UI components to be easily bound to data
models, such as a JavaBeans component or RowSet.
|
org.jdesktop.swing.data |
Contains API used to process data
in a client application, including data models and adapters,
metadata, validation, and type conversion. |
org.jdesktop.swing.decorator |
Contains API used to implement
coordinated sorting, filtering, and highlighting
of the extended Swing cell-rendering component classes
such as JXTable and JTreeTable. |
org.jdesktop.swing.form |
Contains the JForm
component, which enables easy
creation of user-interface forms which bind to arbitrary
data models, such as a JavaBeans component or RowSet. |
org.jdesktop.swing.table |
Contains API required by the extended
JXTable component. |
org.jdesktop.swing.treetable |
Contains API required by the JTreeTable
component. |
This package set will evolve as you help us develop JDNC,
so please see the Swing
Extensions javadoc for the most current package info.
JDNC API
The JDNC API layer contains the high level UI components
which wrap the Swing Extensions layer
to make common use cases easier to construct. These components
are intended to follow the JavaBeans component patterns
whenever possible, so they should be usable within existing
tools, such as NetBeans.
These components will provide attractive default visuals,
usability features, and data binding out of the box so that
a developers can get professional results quickly. These
components are contained in the org.jdesktop.jdnc
package. The initial suite contains:
JNTable: scrollable view on tabular
data (wraps JXTable)JNTreeTable: scrollable outline
view on hierarchical data with columns (wraps JTreeTable)JNForm: container for view/editing
of arbitrary data (wraps JForm and uses binding
framework)JNEditor: scrollable, rich text
editing component (wraps JXEditor) JNTree: scrollable view on hierarchical
data (wraps JXTree)
Admittedly this set is small and by no means includes all
the high level components that developers need to construct
end-to-end enterprise desktop clients. We have a long list
of needed components (login panel, preference sheet, directory
view, data-bound controls, etc.) and we look forward to
expanding this list as you tell us (or contribute!) what
needs to be there. Please see the JDNC
API javadoc for the most current API info.
Note that these components wrap, rather than extend, their
low-level Swing counterparts for a couple of reasons. First,
we want their API to be simpler, which involves more selective
exposure of the low-level component's properties and methods.
Second, we want them to support scrolling and other layout
features with minimal effort from the developer. These components
should be easy for non-Swing developers to use, as they
do not require knowledge of Swing design patterns, such
as swing model interfaces, cell renderers, and the like.
They offer less flexibility, but that's what makes them
simpler to learn and use.
JDNC Markup Language
And last but not least we arrive at the highest level,
the level that initially motivated this project: the JDNC
markup language. The JDNC markup language provides an XML
syntax for configuring rich, data-centric, enterprise clients
that can be easily deployed either as a Java Web Start application,
or as an applet within a browser. The JDNC schema allows
markup developers to assemble clients which leverage the
JDNC components and Swing extensions without having to first
master the APIs or even object-oriented programming. While
XML remains a hot technology, we've learned it's just as
controversial, so let's address the common issues up front.
First, why XML? While it's true that, at
least for us Java geeks, hand editing XML can be more painful
than authoring code in the Java language ("Java code"),
it offers a number of advantages that are particularly well-placed
in the UI arena:
- XML's declarative nature helps constrain the design
problem; while one can spend untold hours pondering
how to organize UI code, XML is basically a tree.
- UI hierarchy is clearly exposed in XML, which
isn't necessarily the case in code.
- XML lends itself to generation and transformation,
which means servers can deal with it.
- XML tools exist today, such as schema guided
editors and graphical viewers, therefore developers can
be productive immediately
Is this comparable to XAML? No. JDNC's XML
configuration language is geared towards expressing rich,
data-centric enterprise clients (as described in previous
section) in the simplest possible manner, and therefore
the schema is intentionally limited. It does not include
general tag support at the UI toolkit or graphics level
and we are not recommending developers use JDNC's XML configuration
for general purpose Swing development. There are existing
toolkit-level XML dialects that can be used for this —
eNode and SwingML
to name a couple — which segues right to the next issue.
So why not use one of the many existing XML UI markup
languages? In our goal to create significant shortcuts
for a small set of common application archetypes, we consciously
chose to define a markup language which was a level higher
than the existing toolkit-level markup languages we were
familiar with. Over time, we may find that many data-centric
enterprise clients will require more fine-grained control
of the UI than the JDNC schema offers, at which time we'll
evaluate the options, as wheel reinvention is a waste of
precious time. Additionally, the JDNC schema has been designed
so that it can be mixed with other XML dialects (for example,
SVG and XForms).
What about XForms? When we implemented JDNC's
basic form functionality, we looked at leveraging the XForms
specification. While XForms is a well-designed specification
that solves the numerous deficiencies in HTML forms, we
were not convinced it would provide the ease of development
and short learning curve we were after. Additionally, implementing
XForms is a significant task which did not fit into our
target schedule for going open source. That said, we intend
to revisit this topic and are open to the opinions of the
development community, as we know lots of brain power went
into that spec.
Can applications be built with JDNC markup and Java
code? Yes! The markup and Java code approaches
are not mutually exclusive and in fact we expect many applications
will be constructed with the combination. For example, a
developer might start out using the markup language to get
the application up quickly, but incorporate business logic
and behavior using Java code. This markup/code integration
is something we need to enhance, going forward.
Deployment of Choice
JDNC is all Java code, therefore the three standard client
deployment options are supported:
When using the JDNC markup language, the same JDNC XML
markup file may be used in all three cases. JDNC provides
the bootstrapping classes (org.jdesktop.jdnc.markup.runner.Application,
org.jdesktop.jdnc.markup.runner.Applet) which interpret
the XML file and realize its contents in the appropriate
top-level UI container (JFrame for applications,
JApplet for applets).
Community Evolution
As promised at the 2003 JavaOneSM
conference, we have released JDNC as an open
source project on javadesktop.org. This enables
us to make the technology available to you early enough
so that you can directly shape the vision, the feature set,
and even the code. There is still a lot of work to do —
the JDNC feature set is far from complete and there remain
rough edges, especially in the API, which has not had extensive
usage outside of unit testing and markup-driven use-cases.
But, that is exactly why we need your involvement.
Join our forum
or use our e-mail
list to talk with us about what problems you're
facing in creating rich, enterprise desktop clients. Tell
us what you find useful and where you think we're off track.
Work with us as we make the technology marry better with
tools. File bugs and requests for enhancements. Submit code
changes. Submit new components. We are anxious to engage
directly with you to make Java desktop client development
as productive and satisfying as we all know it can be.
Read
or Post a Comment
About javadesktop.org and java.net
javadesktop.org
is a java.net community for developers of applications
with rich client interfaces. java.net
is a Web site used by the developer community that expands
the Java technology portfolio of applications, tools and
services in applied areas of technology and vertical industry
solutions. More than 52,000 developers worldwide have
joined the java.net collaborative community, and are engaged
in more than 900 projects ranging from Java technology-based
games development to desktop technologies to enterprise
development such as Java Web services. java.net is sponsored
by Sun, the creator and leading advocate of Java technology,
with editorial resources and technology infrastructure
provided by CollabNet, Inc. and O'Reilly & Associates.
