Develop > Presentation layer > Customize IBM Sales Center > Controls > Managed composites and widget managers
New and existing widget managers
The behavior and properties of the controls in the Sales Center user interface is managed by widget managers. You can declare a widget manager by using the com.ibm.commerce.telesales.widgets.widgetManagers extension point. Widget managers initialize, refresh, save, and dispose of configured controls. They are also responsible for providing the content of table cells. IBM Sales Center provides a standard widget manager that can be used with standard controls and tables. When a configured control is defined, it can be declared with a manager type. The manager type is a hint to the widget manager to decide if the control should be managed by the widget manager. Well-behaved widget managers will only manage controls that have a manager type that they recognize. If a control does not declare a manager type, then it is assumed to be "standard" and StandardWidgetManager will be assigned to manage such controls.
A high-level configured composite can be combined with one or more widget managers to create a managed composite. A managed composite can be declared using the com.ibm.commerce.telesales.widgets.managedComposites extension point. A managed composite is constructed using the managed composite factory. Initialization information will be passed to the managed composite factory and will be available to the widget managers. The composite and its child controls are constructed and events are delegated to the corresponding widget managers.
When to use StandardWidgetManager or when to create a new Widget Manager
A widget manager is responsible for the dynamic behavior for one or more controls (such as text, label, buttons). They are also responsible for providing the content of controls. The StandardWidgetManager provides the standard behavior for the controls that are supported by the Sales Center UI framework and this can be used anywhere while defining these controls. But when add complex behavior, such as adding new listeners, explicitly invoking the events, or modifying the default properties of the controls, we will need a new widget manager. It can add complex behavior by adding listeners and handlers to the control during initialization. This new widget manager should always extend from StandardWidgetManager.
This diagram illustrates the recommended approach for customizing the widget managers. The colored boxes in the diagram are the extended classes for performing the customization. The general guideline is to extend the StandardWidgetManager and use the existing action class to delegate the events. You can extend the Action classes to add any pre or post-processing for any events by overriding the required methods.
Sales Center UI framework is modeled such that you can have control over the customization at various stages. Widget managers contain the logic to manipulate the controls in the UI, so they can be replaced by the new widget managers if different behavior is required. This new widget manager extends from StandardWidgetManager and provides the functionality to the controls. In the same way, actions are mainly responsible for making the server calls, and widget managers use it whenever they need to communicate with WebSphere Commerce Server. A default set of actions is provided by Sales Center for different service requests. You can extend any of these action classes and use their logic to perform any pre or post-processing while making the server calls. Action classes can be used as services; you can use their own actions to perform entirely new service requests.
To demonstrate the flexibility of this approach here are the various steps to customize the widget managers and actions as required:
- All existing widget managers communicate with the WebSphere Commerce Server through the actions by delegating the tasks over them. This way we ensure that widget managers contain logic only to handle the UI controls. They communicate with actions through widget input properties only. (Example: AddressWidgetManager <usage> Actions in the diagram)
- A new action could be extended from existing Sales Center actions to perform some pre- or post-processing before making the server calls. The existing action will be replaced with extended action by using the system configurator. Now the extended action will serve the request from widget manager and will have customized behavior. (Example: AddressWidgetManager <usage> New Actions in the diagram)
- Create new widget manager for customized behavior of UI controls and use the existing actions to perform the service request. (Example: New Widget Manager <usage> Actions in the diagram)
- Create new actions and call them from new widget managers to have completely new behavior for UI controls and different service request. This will be required when the user wants to add new functionality in the Sales Center. (Example: New Widget Manager <usage> New Actions in the diagram)
General guidelines to create new widget managers:
- Use action class for executing any specific tasks in the widget manager, like calling server commands, opening and populating UIs.
- Always communicate between widgets through Widget Input Properties and do not use private instance variables.
- All customized widget managers should extend StandardWidgetManager.
Related concepts
Managed composites and widget managers
Input properties and model path
Related reference