(1) Analysis of flexviewer's overall framework

1. Introduction to flexviewer

The flexviewer framework provides ESRI with a completely free application framework that can efficiently develop web-based geographic information application systems. Currently, there are two versions: one is for a non-developer version, that is, the compiled release version, and the other is for developers to build on the source framework, you can customize your business by modifying code and configuration files.

Here I will discuss with you the developer-oriented flexviewer version.

2. Composition of the flexviewer framework

When we download the flexviewer source code from the Internet and load it through eclipse, we can see the composition structure of the Framework.

 

We can see that there are four subdirectories and three files.

2.1 index. mxml File

This file is the portal of the entire framework. This file is first loaded during system initialization.

2.2 com folder

The content in this folder is crucial. configuration file acquisition and parsing, map initialization and loading, widget loading, and event mechanisms are all related to this folder. This is the file organization in this folder:

 

The following table lists the functions of each module:

File Name	Function
Appevent.	Defines a message class used in the message bus (eventbus ).
Basewidget.	Defines the base class of the widget. All custom widgets must inherit this class.
Configdata.	Defines the type of configuration items used to manage these configuration items after the system loads the configuration items in the config. xml file into the memory during initialization.
Ibasewidget.	The interface basewidget is defined, and the class basewidget implements this interface.
Iinfowindowtemplate.	The infowindowtemplate interface is defined. All custom infowindowtemplates must implement this interface, and the custom template is used in the window definition of infowindow.
Iwidgetcontainer.	Defines the iwidgetcontainer interface. All custom widgetcontainer must implement this interface. Widgetcontainer is an easy visualization tool for managing widgets.
Iwidgettemplate.	The iwidgettemplate interface is defined. All custom widgettemplates must implement this interface, and the custom template is used in the window definition of the widget.
Viewercontainer. mxml	Defines the visual container viewercontainer, which is the root of the component tree in flex viewer.
Configmanager.	The configmanager class is defined. This class is responsible for loading all the configuration information from the config file, storing the information in the data structure configdata, and finally triggering the event appevent. config_loaded releases configdata to other components
Datamanager.	Datamanager is defined to manage and maintain public data in the system, so that all components and widgets in the system can publish public data to datamanager or obtain data released by other components from it.
Eventbus.	Inherits the eventdispatcher interface, and uses the singleton mode to provide unified message registration and publishing functions for all the provided components, so that the components are fully coupled and highly cohesive.
Mapmanager. mxml	Initializes map control, basemap, optlayer, and infographic wwidget corresponding to the optlayer Based on the configuration information in the config file, and provides set_map_navigation (set map browsing tool) and basemap_switch (set basemap_switch) for the event) set_map_action, show_infowindow, map_resize, data_opt_layers (requesting optlayerstable), and map_layer_visible (setting the visibility of specified layers.
Scriptingmanager.	Reserved class, no special purpose
Securitymanager.	Reserved class, no special purpose
Uimanager.	Defines a system UI style sheet based on the style configuration information in the config file.
Widgetmanager.	Automatically initializes the widget container and its contained widget controls based on the configuration of the config file, and provides the event widget_run (open the widget) and data_create_infowidget (create the infowindow corresponding to the optlayer), widget_focus (set the widget to get the focus), and widget_state_changed (close the widget Event Response.

2.3 popups folder

The content of this folder appears only after flexviewer2.3. in this folder, you can configure the display mode of the pop-up box in XML format. The configuration format is as follows:

 

The following is an example of an official ESRI Configuration:

2.4 widgets folder

This is the module part. The flexviewer framework can be understood as a plug-in framework. Under the SRC file, four important parts are defined: plug-in engine, communication mechanism, data storage, and configuration read. Widgets is our independent plug-in, which is called module in flex. Like all plug-in systems, plug-ins must inherit some interfaces, that is, Fixed protocols can be loaded by containers. In flexviewer, ibasewidget and iwidgettemplate are the two interfaces that each custom widget must implement.

2.5 assets folder

This directory is a resource file directory. It is mainly used to manage image files in the project. Other files in the project can access the image resources through relative paths.

2.6 config. xml file

This file is the configuration file, map configuration, widget configuration, and other configurations that need to be used.

2.7 ults.css File

Is the style sheet of the entire system.

3. Framework Startup Process 3.1 instantiation-loading Components

We can see the entire framework startup process from index. xml. Now I will first give the content of index. xml:

 

We can see that the instantiation process is:

 

In the above initialization flowchart, The viewercontainer Initialization is placed at the end, because although viewercontaner is the first to be imported into the memory to start initialization, it is still instantiated all its attributes, so it is put in the final initialization by default.

However, after instantiation, the system starts to load the core modules. These modules will fill the framework in the next series of message triggers.

3.2 message trigger-fill the framework with configuration

First, I will provide the workflow of the message mechanism triggered after instantiation:

 

Next, I will show you the processes related to this message mechanism in the code.

3.2.1viewercontainer triggers read configuration events after instantiation

 

 

3.2.2 after configmanager reads the configuration, the configuration read event is triggered.

Configmanager listens for events initially completed by viewercontainer.

 

In this case, configmanger starts to request the configuration file.

 

After the configuration in cofig. XML is read, the configuration read event is triggered.

 

3.2.3 widgetmanger, mapmanager, datamanager, and other monitoring configurations read the event and respond

All these components are listening to the appevent. config_loaded event. Therefore, after the configuration file is read, these components will respond accordingly.

4. parse the main functions of Core Components

The flexviewer architecture is given first:

 

 

4.1configmanger -- read Configuration

 

If the configuration file is not modified, the default address is used:

 

To modify the attributes, you can find the relevant attributes in viewercontainer and modify them.

Parse the configuration in the config file in the configservice_resulthandler function. In the source code, geoserverurl and so on are parsed and put into configdata.. However, this is not fixed. When you modify and expand the framework by yourself, you may need to add the required configuration in the config file and add it to other custom files after parsing. This component can also read the widget-related configuration and save it to the corresponding properties of configdata:

 

 

4.2datamanager -- data sharing

When we look at the datamanager code, we will first find that this class is a class inherited from eventdispatcher. It is not difficult to deduce that this class must be related to the message mechanism, but what is the role of this class?

After reading the methods in this class, you can guess their functions. This class is used to store messages, distribute messages, and share messages. For example, flexviewer is a modular framework. A widget is instantiated only when called. Therefore, when widgeta has sent several messages, widgetb is called and instantiated, in this case, how does widgetb obtain the message in widgeta that it misses. Datamanger can solve this problem.

 

4.3mapmanager-map loading and Configuration

There are several methods in mapmanager:

 

These methods can instantiate the basic maps and map operations configured in the configuration file. In addition, all these methods need to call a common function: addlayertomap (layerobject: object ). So the instantiation of different types of maps is controlled here. If you have extended some custom map types, you need to add support for custom map types in this function.

4.4widgetmanager -- associate the plug-in with the host

The loadcontainer and loadcontrol methods are used to load plug-in containers and specific plug-ins.

4.5uimanager-UI control

This class is mainly used to control the framework style. The style configuration is carried out in config. xml.

5. Summary

Above I will roughly describe the construction of the flexviewer framework and its message mechanism during initialization, and give a general introduction to the core components. Using the flexviewer framework, you can quickly develop a front-end with good results. Here I will provide a project example, which is modified, extended, and developed on the basis of flexviewer. In the subsequent sections, I will share with you how to expand the map class, how to make widgets, and how to configure the config. xml file related to the example. I believe that through instance exploration, you will have a deeper understanding of the flexviewer framework.