Dashboards & Tools Framework Overview
The Dashboards & Tools framework enables you to build interfaces in which a set of UI
components can be edited by end users, saved and later restored.
This includes interfaces such as:
- Dashboards: where a library of possible widgets can be created &
configured then stored for future use and shared with other users
- Diagramming & Flowchart tools: tools similar to Visio™ which allows users
to use shapes and connectors to create a flowchart or diagram
- Form Builders & Development Tools: tools which enable end users to create
new forms or entirely new screens and add them to the application on the fly
The basic building blocks of the Dashboards & Tools framework are:
- Palettes: palettes create UI components on the fly from stored data. Palettes
come in a variety of flavors which implement different UI gestures for creating components
(e.g. drag from tree, pick from menu, etc)
- EditContexts: an edit context tracks a set of components that are being edited.
Different EditContexts offer different built-in user interactions for editing the
components they track, for example, a tree-based EditContext can provide an interface for
managing relationships between components via drag and drop, and a Canvas-based EditContext
can automatically store changes to position and size.
Defaults vs LiveObject
The Dashboards & Tools framework is careful to maintain a distinction between the current state
of the live UI component and the data that should actually be persisted and used to
re-create the component. For example:
- a portlet may be showing a border or brightened background color to hilite it within
the tool, but this should not be saved as part of the portlet state
- a component may have a current width of 510 pixels when viewed within a tool, but what
should persist is the configured width of 40% of available space
- in a development tool, a component such a Window automatically creates subcomponents
such as a header - these should not persist because the Window knows how to create them
without any additional data. Only components specifically dragged into the Window by the
end user should be persisted
The data that will be saved and used to re-create the component is called the
defaults. A Palette, which creates a component from stored data, minimally requires
the String of the component to create, and the defaults. This
information is captured by a
PaletteNode (along with other
options) - all types of
Palettes work with a set or tree of paletteNodes.
When a component is created from a paletteNode, a "live object" is created from the
defaults. One PaletteNode may generate any number of live objects. An EditNode
combines the live object along with
the type and defaults
needed to recreate the live object, and is used to track the created live object as it is
further edited. Essentially an EditNode is a copy of the PaletteNode in which a live object
has been created and the editNode.defaults may now begin to change as the user edits the
object they have created.
Module requirements
NOTE: you must load the Tools
Optional Module
for this framework.
Any tools that work with hierarchies of system components or derivations
of them will also need the system schema which can be loaded by either of the
following:
JSP tag:
<script><isomorphic:loadSystemSchema /></script>
HTML tag:
<SCRIPT
SRC="../isomorphic/DataSourceLoader?dataSource=$systemSchema"></SCRIPT>