Usage of descriptions
To get an idea about how to use the built description(s) have a look at the examples. Basically the usage is a three-step process:
- Create and fill a container
- Customize the widgets' visual aspects
- Bind the widgets to custom data/events
Create and fill a container
UIBuilder uses the LayoutDescription to create a FormLayout, uses the given Constraints to create the raw components (actually delegating to a UIFactory) and inserts them into a container. At this point every component has a (hopefully - it's not yet formally enforced) unique name to identify it later on.
The UIFactory uses a pluggable ComponentTypeMap to map generic widget types to (J)Components and creates them assuming a parameterless constructor. The default map is SwingComponentTypeMap which has entries for all standard JComponents.
Components which "usually" are presented inside a scrollpane (JTable, JTree, ....) are automatically inserted into a scrollpane with the same name
Customize the widgets' visual aspects
PresentationManager is responsible: for each widget it uses a registered Customizer and transfers the presentation attributes into some meaningful property in the context of the widget class.
The DefaultPresentationManager can set the "labelFor" property of a label: given a component with name "XX" a label in the same form with name "XXLabel" is assumed to be the label for the component.
SwingCustomizerMap uses a ButtonCustomizer to customize AbstractButtons. This customizer registers default actions (DelegateAction as used in the ActionFramework article by Mark Davidson) with the ActionFactory. Application code should not set custom actions to buttons but register a custom handler for the action with the ActionFactory. The registered handling code can be either a callback method or an action (have a look at the examples to see what I mean :-). The idea is that the Presentation drives the viewable attributes of the action but should be separated from the actual performing code...
Bind the widgets to custom data/events
From here on the application code takes over and wires the components to custom models/properties/action handling code. The se-binding part of the framework provides a thin layer on top of JGoodies Binding to map named components to bean properties.
BeanBinding is the central support to facilitate the task (see examples and api doc). [TBD: explain...]
Note: loader.jar is independent of se-binding, so developers are free to choose a different binding approach.
Actually, the first two are handled internally by FormLoader: all it needs is the name
of a description resource (located at one of the places documented in ResourceManager api) -
it will read the descriptions, delegate the creation of the container with
components to a UIBuilder and delegate the customization of the container
to a PresentationManager.