The interface combination SDK based on Flex

The following is an interface similar to the main interface of a product we are developing, with flex developed on the front end and a java-based SOA framework for the backend system. The left side of the interface is the navigation bar, the right side is the content area (and, of course, other columns, ignored here). The content area is typically composed of multiple UI parts, each using an asynchronous mechanism to fetch data from the backend, and it will also receive notification messages from the back end. The entire interface fits well with the Microsoft Cab idea, but Flex doesn't have a cab build, but you can define a piece of content in a Microsoft User control way. The UI part of the interface content area may be reused.

In design, I want to use the idea of interface combination to design, the advantages of this idea are: 1 The interface is divided into different components, each part to achieve a function, more in line with the SRP principle; 2 when implementing each UI part, it is simpler to focus on a piece of content in a complex interface; 3. Easy to implement The disadvantages are as follows: 1 Each interface consists of multiple UI parts, maintaining the connection between the UI parts; 2 The novice is not easy to understand the implementation of the interface.

Given the many advantages of the Microsoft interface, I decided to introduce my ideas to flex and implement a composition SDK based on Flex, which referenced cab & SCSF and Prism during the SDK implementation.

Given the functionality that the software needs to implement, this SDK will support the following features:

1 UI part life cycle management. Each UI part needs to get the data from the backend, and then listen for data update messages, and when you click Tab 2 in the Interface, tab 1 is hidden and stops listening for messages, and tab 2 is displayed. In my opinion, each UI part has a activated, deactivated, and closed lifecycle state, and when in the activated state, the UI part displays the required data, and when in the deactivated state, the UI Part is hidden and stops updating the data, and when in the closed state, the UI part is closed and the data is stopped, and it is destroyed. The purpose of lifecycle management is to implement lifecycle change driven data update, that is, each component data update is determined by its own lifecycle state, do not need to be controlled by the parent node, so as to achieve greater granularity reuse.

2 UI part combination and dynamic injection. This feature allows you to define each UI part directly in the View container class. In this way, once the container is displayed, all UI parts are displayed, or some UI part is dynamically injected and rendered at run time, and the specific UI part is injected as needed when the container is rendered.

3 Master-details UI part support. The Master-details UI part is a special pair of UI part that, when the data for the master UI is changed, also needs to be updated in the Details UI, as is the master-details view of. Net.

4 The hook mechanism is implemented so that when implementing the 1~3 function, it is possible to be compatible with standard controls, without creating custom controls or just creating very simple custom controls. The principle of hook mechanism is as follows: a) each function is implemented by a hook; B For example Lifecyclehook, for a leaf node component, when it is shown/hidden/closed, it maintains its state, and for a container node, it is not only maintaining its own state, but also To maintain the state of a child control, such as a VBox container, when VBox is displayed, its state is activated and all its first-level child node states are activated, and for the Tabnavigator container, when it is displayed, Its status is activated and the currently selected tab state is also activated, the rest of the tab state is Deactivated;c) hook is the creation of a recursive listener interface root node onchildadded/removed event (D) The SDK provides the hook registry and Hook manager, and the hook registry defines the hooks for each type of component, and the hook manager defines the hook instance for each control.