The controller

The controller is used for configuring view parameters, including layout and the background map. It manages the toolbar and the interactors: it determines which interactors are available from the toolbar.

The controller manages end-user interaction, such as object creation or move requests. It forwards these requests to the handler (see The handler). It forwards all end-user requests to:

create objects
delete objects

and actions triggered by the end user to:

move objects
reshape objects

Classes of the network controller

The IlpNetwork class automatically instantiates the class IlpNetworkController.

Using the network controller

The normal way of customizing the behavior of the controller is to attach a handler through the API.

The default handler is the IlpNetworkHandlerWithoutDataSource. When a mutable data source is connected to the network component, a new handler, IlpNetworkHandlerWithDataSource, is attached to the controller. You can customize either of these handlers by extending them. To set a new handler, use the method setHandler:

IlpNetwork network = ...
IlpNetworkController controller = network.getController();
IlpNetworkHandler myHandler = new MyCustomHandler();
controller.setHandler(myHandler);

Another controller configuration is to set the default view interactor through the method setDefaultViewInteractor . See also Interacting with the network view.

You can also customize the controller by using CSS rules in the network configuration. The following code gives an example. For more details, see Configuring a network component through a CSS file.

How to customize the network controller through CSS

Interactor {
  name: "Select";
}

This rule selects the default interactor.

The handler

In the same way as the adapter passes information about the objects in the data source to the network component, the handler passes information in the opposite direction, that is, from the network component to the data source.

The information notified in this way includes:

Actions triggered by interactors for
- Creating objects in the data source
- Removing objects from the data source
- Changing attributes of objects in the data source
- Changing the parent object of an object in the data source
- Expanding and collapsing container objects
Propagating position changes of objects

The position changes are usually due to layout, zoom change, or interactors.

The handler has been designed to simplify the customization of user interactions without rewriting the controller.

Any user interaction with the network is processed by the network controller which delegates action to the network handler. The handler has two default implementations:

IlpNetworkHandlerWithoutDataSource is attached by default to the controller and performs user interactions directly in the network model.
IlpNetworkHandlerWithDataSource is automatically attached to the controller when a data source is connected with the network component. User interactions are executed inside the data source that will notify the adapter, and the adapter in turn will notify the network model. In this particular use case, changes will be reflected on all network components, if any, connected to the data source.

There are four types of handler:

IlpPositionHandler to handle object position changes.
IlpNodeHandler to handle object additions, removals and updates, as well as relationship changes.
IlpLoadHandler to handle reloading of model objects from an XML file.
IlpExpansionHandler to handle the expansion and collapsing of objects.

The IlpNetworkHandler interface indirectly extends all four types of handler.

Custom subclasses of IlpNetworkHandler can be set using the controller.setHandler() method. It is possible to customize handlers separately by implementing the specific interface (for example, IlpNodeHandler) and setting it with the corresponding controller method (for example, controller.setNodeHandler()).

The handler has a reference to the data source in the form of an IlpMutableDataSource, and to the network adapter.

The JViews TGO default handler is only compatible with data sources that implement the IlpMutableDataSource interface.

You can customize the behavior of the handler by subclassing the class IlpNetworkHandlerWithDataSource. A particular method can be overridden for each of the possible actions.

A custom handler that is a subclass of IlpNetworkHandlerWithDataSource is automatically connected to a mutable data source.

It is the user's responsibility to manually connect a handler to a data source when one the following conditions applies:

The handler is not a subclass of IlpNetworkHandlerWithDataSource.
The data source does not implement the interface IlpMutableDataSource.

In this case, it is mandatory to create a custom handler and to design a way to connect the handler with the data source.

You can customize the way position changes are propagated by overriding the method propagatePositionToDataSource. In a typical situation where the client is active, position changes are propagated to the data source. Therefore, this method returns true by default. In a situation where the client has read-only access, you may want to allow only user-requested position changes or no position changes at all to be forwarded to the data source. You can achieve this result by allowing the method propagatePositionToDataSource to return false in the appropriate cases.

The handler is most often subclassed to allow you to customize the creation of new objects in the data source. The object interactors may need to be customized in the same way. A customized object creation interactor typically calls the controller method createObject with specific properties. The controller then forwards these properties to the handler. Finally, the method handleCreateObject of the handler parses the additional properties and creates the new objects.

By default, the handler creates new objects in two steps:

The ID of the new object is created with the method createObjectId.
The IlpObject corresponding to this ID is created with the method createObject.

You can customize each step separately by overriding these methods in a subclass.

Current section

Architecture of the network component