The primary purpose of beans is to enable the visual construction of
applications. You've probably used or seen applications like Visual Basic,
Visual Age, or Delphi. These tools are referred to as visual
application builders, or builder
tools for short.
Typically such tools are GUI applications, although they need not be. There
is usually a palette of components available from which a program designer
can drag items and place them on a form or client window.
In Windows environments the form is often called the client window area.
The form, or client window, represents the target application under
construction and is presented, during design, as it will appear when it runs
independently of the builder program.
The most tell-tale window shared by many popular application builders is a
property sheet, sometimes called a
property editor or simply a properties
window.
A property sheet is used to modify properties and
events associated with components. In keeping with
Java AWT terminology some property editors use the term action in
place of event.
Applications built with powerful components can appear complex even when they
take little effort to build.
Linking Components in Builder Tools
The calculator program shown earlier is a good example of building a complex
program with no handwritten code.
The calculator was built without writing any Java code. Instead, components
were linked by using a mouse. Generated events and event-handler methods were
selected through pop-up menus.
Every time a button is pressed, an event is fired and side effects result.
Example side effects include appending digits to the invisible EnteredString
storage buffer, performing a math operation, or displaying text in the display
pane. To program an event sequence, select a button as the event source, and
indicate that you want to fire an event through a keystroke or menu command.
You'll see a menu, or a property sheet, listing events that can be fired.
Select an event, then drag a link to the target object which should receive
the event. You will be presented with a menu listing event handlers available
for the target object.
The following sequence of screens shows a more complex example in a different
builder tool. An animation component is added to a subpanel within a client
window. First an Animation Bean is selected from the builder's palette and
dropped on a panel object in the client form.
A Bean is customized by selecting action items from a property sheet, which in
turn invokes a custom Bean editor to select a specific event from a list of
events that can be generated by an Animation Bean. A list of events is
acquired by introspection; the builder tool uses Java introspection APIs to
query beans dropped on the form.
Default behavior for event handlers is usually acceptable, but in some cases
you'll want to manually override handler definitions with a text editor.
In this builder tool, much of the programming, including selection of events
and event handlers, is done using a class hierarchy browser. After selecting
the event-handler method, a template for the event handler is generated, while
you flesh out details manually by writing code in the browser.
However not all programs require text editing. As mentioned, the calcualtor
example was built without resorting to text coding. The maze of links required to hookup components can be overwhelming, as you can see in the following figure.
But, most builder tools allow you to easily edit links and filter the display
of links so that you see only the level of detail that you want.
Nesting Components
Once you have assembled components into an application, often that application
itself can be turned into a component. An earlier example showed an Animation
component dropped onto a panel to display an animation. Most of the code for
the example was created through menu selections. The component was customized
primarily by specifying the names of animation files to be displayed from the
disk. The mouseDrag event handler was overriden through the browser for
detailed customization.
Once custom properties and behavior are defined, they can be preserved by
making a new Bean out of the customized instance. This is usually accomplished
by serializing the customized Bean using Java's built-in support for object
serialization. Most builder tools provide a way to turn compound components
into custom Beans. In this example you select the Animation Bean, and issue
a menu command to turn it into a Bean component.
The builder generates code to turn the assembly (property and behavior
definitions) into a Bean. The bean is added to the component palette of the
builder tool. Alternately the bean can be packaged in a JAR archive file for
sale, or distribution to clients.
You could take the new custom Bean and use it to compose a compound assembly,
creating yet another custom Bean. For example, you could group three instance
of a MyAnimationBean on a panel and save the whole assembly as a single new
Bean. The compound MyThreeBeans custom component is added to your builder's
component palette as a single Bean.
But I hate GUI builders
Over and over again, you hear advanced programmers say that builder tools are
more trouble than they are worth. "If you really know what you are
doing," they say, "You're best off building code for GUI applications
by hand. I've tried GUI builder tools, and they're more trouble than they're
worth."
To be clear, a GUI builder, or window builder, is a different beast than an
application builder. Many programmers are familiar with window builders and
their limitations. In a window builder you design screens visually, and code
is generated thatbecomes part of an application built with traditional
compilation tools.
Application builders let you do all of this, but in addition, they let you
visually hook up components, select events to be fired, and handlers for
events through mouse drag, or menu selection. Very little code needs to be
written by hand to get the initial component interaction working properly--at
least in comparison to a GUI builder or a window builder.
Also, GUI bulders are typically one-way tools. They allow you to build your
interface visually and generate code from a project file. In most cases,
however, if you edit the generated code manually, the changes are not
propagated backward to the visual representation of the application in the
project file.
Tools like Delphi and Visual Basic are much more sophisticated than traditional
GUI builders in that modified code does propagate backward to the visual
representation. Powerful language parsers are required to make this work
properly. The text is parsed and the new representation of visual objects
is merged with the old representation (sort of like a binary diff utility).
Because older window builders did not provide such a capability, many
programmers became frustrated with the tools once they moved past early
design stages. They rightly concluded that only a minor amount of work
goes into the physical layout of GUI components. Most of the work for any
application goes into component hook up, event generation, and event handling
methods.
Unfortunately, many programmers, familiar only with the older window builder
tools, believe the current generation of application builders suffer from the
same restrictions. However, the current generation of builder tools provides
enough flexibility and power to warrant another look.
To Top