图 3.1 Flex Viewer整体结构
3.3 初始化那些事儿
在浏览器地址栏输入Flex Viewer的地址，经过短暂等待，当她华丽丽地展现在我们眼前，你是否想过在这短暂的等待中，Flex Viewer都做了哪些事情呢？本小节我们来探讨Flex Viewer初始化那些事儿。注意，我们这里所说的Flex Viewer初始化，不是Flex概念中组件生命周期的初始化部分，而是指Flex Viewer在可以与用户交互之前，所做的准备工作。
图 3.2 Flex Viewer初始化过程
3.2小节中，我们强调通过使用事件，Flex Viewer将各模块之间充分解耦。实际上，事件也伴随着Flex Viewer初始化的整个过程。Flex Viewer的初始化过程如图3.2所示。
1) 首先观察一下ConfigManager的构造方法，其中有这样一句代码：
ViewerContainer.addEventListener(ViewerContainer.CONTAINER_INITIALIZED, init);
也就是说，ConfigManager实例在构造期间就通过ViewerContainer在EventBus的单例添加了对CONTAINER_INITIALIZED事件的监听，一旦ViewerContainer在别的地方派发了CONTAINER_INITIALIZED事件，ConfigManager将响应该事件，开始读取配置文件、解析配置文件，构造ConfigData数据，最后将ConfigData连同CONFIG_LOADED事件派发出去，见下面代码：
ViewerContainer.dispatchEvent(new AppEvent(AppEvent.CONFIG_LOADED, configData));
2) 我们再观察一下UIManager、WidgetManager和MapManager的代码，在各自的初始化代码中，都可以找到下面一句代码，此处不再解释：
ViewerContainer.addEventListener(AppEvent.CONFIG_LOADED, config);
3) 最后，问题的关键在于CONTAINER_INITIALIZED事件何时何地被派发？我们观察一下ViewerContainer的init()方法，其中有下面这句代码：
ViewerContainer.dispatch(ViewerContainer.CONTAINER_INITIALIZED);
而init()方法是ViewerContainer的creationComplete事件的响应方法。也就是说ViewerContainer初始化结束才是Flex Viewer初始化的开始。
Flex Viewer初始化的脉络已经相当清晰，ConfigManager、UIManager、WidgetManager、MapManager在各自的初始化过程中对相应的事件进行监听，一旦ViewerContainer初始化完成，派发出CONTAINER_INITIALIZED事件，其它的准备工作将顺其自然，水到渠成。
我们注意到，初始化过程所涉及的各个模块都是相互透明的，彼此并不知道有对方的存在，而这些模块之所以能够亲密协作，关键就在于它们都只关心事件，事件机制使得这些模块之间实现松耦合。实际上，事件充斥着Flex Viewer的各个角落，随着对Flex Viewer理解的逐渐深入，对这一点的体会将更加明显。
3.4 Widget设计及实现
一个Widget是对一组相关操作的封装，这些相关操作完成某项特定业务功能。Widget不仅可以调用地图资源，也可以访问服务器端资源。Widget基于Flex Module，编译后是独立的swf文件，这样一来，将具体的业务逻辑封装在Widget中，减小了系统主体的体积，在业务功能较多时，可显著缩短系统加载时间。加之面向接口编程和依赖注入思想的应用，Flex Viewer中的Widget可以独立开发，通过配置文件决定提供哪些Widget，从而决定系统提供哪些业务功能。可以把Widget理解为“插件”。这种灵活的“插件”机制是如何实现的呢？下面我们了解一下Widget编程模型，如图3.3所示。
图 3.3 Widget编程模型
Widget分为两种，Control Widget和Business Widget。Control Widget是指控制组件，比如NavigationWidget、HeaderControllerWidget、OverviewMapWidget等，这些Widget提供系统级别的功能，不针对具体业务功能；Business Widget是指业务组件，比如SearchWidget、BookmarWidget、GeoRSSWidget等，这些Widget提供具体业务功能。两种Widget都继承自BaseWidget，都由WidgetManager来管理，不同的是，在WidgetManager中有一个WidgetContainer来专门管理Business Widget。
两种Widget有共同的父类BaseWidget，BaseWidget实现了接口IBaseWidget，两者也就有了共同的接口。WidgetManager通过IBaseWidget来管理Widget，与具体的Widget解耦。Flex Viewer此处使用面向接口编程和依赖注入，实现了主体系统与Widget的松耦合。
u IBaseWidget
该接口定义了WidgetManager与Widget进行交互的方法，BaseWidget实现了这个接口。
u BaseWidget
该类是所有Widget的基类。只要某一组件继承自BaseWidget，WidgetManager即可对其进行管理。由于BaseWidget继承自Module，每一个Widget都将编译成独立的swf文件。
但两种Widget在具体实现上有所不同。Flex Viewer为Business Widget提供了统一的UI基类和接口，也就是WidgetTemplate和IWidgetTemplate。通常情况下，Control Widget都会使用自定义UI，但是这不是必须的。
u IWidgetTemplate
该接口定义了BaseWidget与WidgetTemplate交互的方法。WidgetTemplate实现了这一接口。
u WidgetTemplate
该类是IWidgetTemplate的一种默认实现，在具体的Widget实现中，同样可以使用自定义的WidgetTemplate，只要实现IWidgetTemplate接口即可。WidgetTemplate为Widget提供基本UI控件，包括窗口面板、带有图片按钮的标题栏等。使用Flex Viewer实现的WidgetTemplate，开发人员可以将更多的精力和时间放在实现业务逻辑上。
需要说明的是，Widget的设计在Flex Viewer 1.x版本和2.x版本中有所区别。在1.x中不存在Control Widget，比如菜单组件，菜单项是可配置的，但是菜单组件本身是不可配置的。2.x版本以后，Widget的概念扩大了，Flex Viewer中，凡是能看到的组件都是Widget，这样一来，控制组件可以像业务组件一样可配置，比如HeaderControllerWidget，灵活性大大提高。