Toolkit Overview

How it works...

In a nutshell, at the heart of the diagram is a list of display elements and a collection of renderers. When the diagram repaints, the renderers are applied to each element in turn to generate the graphics for the diagram. The renderers can be configured to render elements with different property values differently.

What about data?

The diagram works with data objects that have keys and properties. Keep them in a data model and send data events to the diagram, or just use the data objects. We provide a support class that takes care of the event handling. You can also mock up data in a file or use a Swing TableModel.

What are elements for?

The diagram needs some display information for each object, and this is maintained by the display elements, usually one display element per data object. You can store application parameters in the elements too. Or if your data is not in the right format (or you don't have any to start with), you can extend the toolkit's display element class to do whatever you need.

The diagram's element model creates display elements for data objects automatically (optionally using your factory class), or if it already has elements, it matches them to data objects by key.

What do the renderers do?

Painting renderers paint shapes, text, or images, offset and aligned at each element's position or relative to another renderer's graphic. There are also renderers to enclose another renderer's graphic, draw formatted text, and render a javax.swing.Icon instance. Their properties include scalability, transforms, converters, selection properties, and all the usual graphic attributes.

But the point is to communicate information about the data objects and their properties. Features such as data binding, delegating renderers, value maps, script expressions, and configuration objects or scripts give you complete flexibility and control over what gets rendered for each element based on data values.

And put it all together in a concise JavaScript-hosted declarative syntax.

Who positions the elements?

There's a way to suit every application. Get positions from the data or from an HTML image map. Set them interactively in the toolkit's design editor or define them in your application.

Implement a custom layout manager or use our TreeLayout, Weekly Schedule or ResourceChart models. Layout managers can be incremental or deferred, and can do layout to the diagram's size.

What's showing in the diagram?

By default all the elements, centered in the window. Use parameters like the view bounds, anchor, alignment, scale, margins, and resize policy for precise control.

What else can the diagram do?

Many other things, like scrolling, zooming, tooltips, printing, and generating images, not to mention a background image or gradient.

The toolkit has features like logging and tracing to help you track down problems, and converters to work with your data values.

Can the user click in the diagram?

Of course. Selection parameters control what is selected, and you can register listeners for selection, tag selection (selecting a subpart of an element), and mouse events. Simpler applications just query the selection when they need to.

What else is in the toolkit?

There's Geo, the toolkit's design editor, and the property editors and customizer used with IDEs. With Geo you can prototype your diagram's style using your data, modeling classes and renderers.

Besides the API documentation, there's an extensive and detailed Developers' Guide, tutorials, a dozen demos, and a large number of small example programs to help you get started.

And now it supports JavaServer Faces?

The JSF layer wraps the diagram in JSF components, one for selecting elements and one for submitting the form. You configure the diagram like you would for Swing, in a handler class. The JSF layer generates the HTML and images and provides the JavaScript to make the diagram work.

Won't that be slow?

We've gone to extra effort to build enhanced rendering and image generation into the JSF layer to minimize server requests and to enable cross-browser rendering, selection, rollover and scrolling with good performance.

On the server we've added concurrency management at the diagram level so the diagram is only updated as needed, and your clients can share diagrams for more efficient server utilization.

Is it scriptable?

Absolutely. With JavaScript event handlers, user-callable functions, and asynchronous updating, you can integrate the diagram seamlessly into your page.

About our architecture...

With most other toolkits, you get a library of graphic components and you instantiate what you need and perhaps build a hierarchy that renders itself when asked.

Our diagram has a highly modular framework architecture with a clear separation between data, display parameters and renderers. We think this makes the diagram...

• More structured. Knowing more about your diagram, we are better able to handle things like selection, display in a browser, and data updates. Saves you time too because we've provided the framework and the glue code for you.
• More pluggable. The layout manager, for example, or the different ways to build your element model. You just add the custom modules you need, we've worried about how it all fits together and who needs to be updated when. Or use our modules, they're very configurable.
• More toolable. Like Geo, the toolkit's design editor, helping you position elements and build your renderers without compiling a single line of code. So we can save you even more time in the future.

Please note, the toolkit requires Java 6 with the embedded Mozilla Rhino JavaScript engine.

Explore further...

New Features ...

List of Features ...

Developers' Guide Table of Contents ...

List of Examples ...

*The Swing TableModel adapter, multiple selection, selection tags, and mouse events only apply to the Swing edition.