An Introduction to the Diagram Components
Types of diagram components?
The HTML diagram uses our innovative cross-browser display technology to display diagrams in web browsers using images, HTML, CSS and JavaScript. The JavaServer Faces components and the WEBDiagrams online diagram service are built around this diagram component.
The Swing diagram is for Swing applications and applets. A third diagram component generates images. All components share the same configurable and pluggable diagramming framework.
Where does the data fit in?
The diagram displays data objects that have keys and properties. Data objects with different property values can be displayed differently.
The toolkit's diagramming framework can accept data objects directly or access them through a data model that fires events when the data changes. We provide a support class to help build data models. You can also mock up data in a file, and for Swing diagrams, use a Swing TableModel.
What are display elements?
The diagram needs some display information for each object, and this is maintained by the display elements. You can set application attributes on the display elements, or extend the toolkit's display element class to access data and add application functionality.
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.
How are objects displayed?
Objects are displayed with renderers. 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 displayed for each object based on data values.
And put it all together in a concise JavaScript-hosted declarative syntax.
How are objects positioned?
There's a way to suit every application. Get positions from the data or from an HTML image map. Position them interactively in the toolkit's design editor or set 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 shown 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.
Any other features?
Many other things, like scrolling, zooming, rollovers or tooltips, and a background image or gradient.
User interaction?
Browser-based diagrams offer object selection and rollover with JavaScript event handlers and a selection API. JSF components support server-side listeners and a selection API.
Swing components use a configurable selection model supporting selection of objects or components of an object, mouse events, event handlers, and a selection API.
JavaServer Faces components?
There are two JSF components, an Input component for selecting objects and a Command component for submitting the form. The HTML diagram generates the images, HTML and JavaScript to build the diagram and handle its operation.
The JSF 2.0 library supports Facelets with partial updates through <f:ajax .../>, allowing better application integration with less JavaScript.
Are they scriptable?
Absolutely. With JavaScript event handlers, a user-callable API and smooth asynchronous updating, the diagram integrates seamlessly into your page.
What about performance?
We've gone to extra effort to build enhanced rendering and image generation into the HTML diagram layer to minimize server requests and to enable cross-browser rendering, selection, rollover and scrolling with good performance.
On the server our end-to-end framework only updates diagrams as necessary and manages concurrency at all levels, enabling clients and requests to share diagrams if possible for faster response and better server utilization. We continue to look for new ways to improve performance.
What else is in the toolkit?
The toolkit also has features like logging and tracing to help you track down problems, and converters to work with your data values.
Geo, the toolkit's design editor, lets you 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.
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 renderering. 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 components require Java 6 with the embedded Mozilla Rhino JavaScript engine.
