3.1.3 电源与插槽 —— 网页模板和网页布局定义文件
我们已经有了一个强大的基础平台，也定义好了一些功能强大的小工具，就好比我们一台电脑已经有了一个强大的主板（包括 CPU 和硬盘）和各种我们需要的板卡。但我们还有两个问题没有解决：一是我们缺少一个启动用的电源，也就是承载框架的网页。 Fusion 框架是一套 Javascript 框架，而浏览器只能用于浏览网页，而不能直接执行一段脚本的。因此，我们需要有一个网页来启动整个 Fusion 系统；二是我们缺少板卡插在主板上的插槽，也就是定义如何加载和显示小工具的定义文件。
网页模板和网页布局定义文件，正好解决了这两个问题。网页模板和网页布局共同定义了如何小工具与 Fusion 基础平台的运行方式。
网页模板一般由一个模板说明文件，一个 HTML 网页，一个默认应用程序定义文件，一个预览图片和用到的若干样式表、图片文件构成。其中 HTML 网页定义了网页中各元素之间的位置关系并负责启动 Fusion 框架，而其余各文件主要用于为 MapGuide 配置工具提供相应的信息来生成网页布局定义文件。
默认情况下，当您打开“ <FusionRoot>/templates/mapguide ”文件夹，就会发现里面有大量的子文件夹和 XML 文件。这里面 XML 文件是对模板中各个元素的定义，而那些子文件夹里面包含的就是模板（您也可以通过修改 <WebRoot>/webconfig.ini 配置文件下 WebApplicationProperties 组下的 TemplateRootFolder 项的值来改变该文件夹的位置）。
我们以 slate 模板为例，解释一下模板文件的大体结构：
“ <FusionRoot>/templates/mapguide/slate.xml ”是用于描述该模板中存在的元素的，该文件将来会被 MapGuide 配置工具用到。该文件除了常见的名称、模板位置、描述、缩略图位置等信息外，还会有大量的 Panel 子节点，这里面的每一个子节点就是一个用于界面布局的元素。其 Name 将来会被用在 HTML 网页中用来表示各元素之间的位置关系。
“ <FusionRoot>/template/mapguide/slate/ApplicationDefinition.xml ”是将来会被 MapGuide 配置工具参考，用来生成网页布局文件的模板，其结构与最终生成的模板基本相似。而“ <FusionRoot>/template/mapguide/slate/preview.png ”用来让 MapGuide 配置工具做为模板预览的图片，一般大小为 126*96 。模板文件夹下众多的 CSS 文件和 images 文件夹下的图片是在浏览器中显示的样式表和图片。
在模板所包含的文件中，最为举足轻重的就是模板的主页面，也就是“ <FusionRoot>/template/mapguide/slate/index.html ”。该文件定义了如何启动 Fusion 框架，采用的样式和各元素之间的位置关系。我们以开源版 MapGuide 中的该文件为例，其他版本行号可能略有不同，但整体结构基本一致。
在该文件的第 7 行，该页面引入了 Fusion 框架脚本代码。通常有三种方式引入 Fusion 框架：
1. 分散文件方式：引入的文件为“ <FusionRoot>/lib/fusion.js ”，其他 Fusion 框架需要的代码会由该文件内的脚本引入。这种引入方式由于会请求大量的文件，因此会在浏览器和服务器产生多次请求，效率最低，但易于调试。
2. 独立文件方式：引入的文件为“ <FusionRoot>/lib/fusionSF.js ”，这里 SF 是“独立文件（ Single File ）的缩写”，这个文件包含了 Fusion 基础平台和 Fusion 内置小工具的全部代码，而且没有经过任何处理，保留了源代码中所有空白和格式。这种方法虽然引入的脚本文件大，但由于只产生一次请求，所以效率比上一种方式高。但是，由于该文件含有上万行脚本，因此不建议将其用于调试。如果机器性能不高，那么在浏览器的调试器加载该文件时有可能会出现死机。
3. 独立压缩方式：引入的文件为“ <FusionRoot>/lib/fusionSF-compressed.js ”，这个文件是在 fusionSF.js 的基础上，通过删除无用的空白，并进行了适当的混淆生成的。该代码可读性差，但执行效果与前两种方法的效果完全相同。由于该文件删去了无用的部分，因此整体大小要远小于 fusionSF.js ，所以效率在三种加载方式中最高。
在 8-15 行，该文件引入了所需的样式表文件。然后便是大量的脚本定义。这其中最重要的是在 23-96 行，该脚本定义了一个函数，并把它作为 window.onload 的执行函数。这就使得该函数中定义的脚本会在页面加载完毕时得到执行。这段初始化函数包括如下内容：
a) 24 行初始化了 Fusion 的区域信息，该信息将会用于对脚本中的字符串进行本地化。如果有哪些代码应用到了本地化的字符串，一定要保证该行代码在这行代码之后执行
b) 26-82 行初始化了各个元素之间的位置关系。这部分和 HTML 中相应的标签合在一起，定义了各个元素之间的位置关系。调整这里的数据，会改变最终网页中各元素显示的位置。比如，在 29 行有如下代码：
new Jx.Layout('SplitterArea', {left: 2, right: 2, top: 2, bottom: 23});
该代码表示的是 SplitterArea 会在其父节点（也就是 143 行定义的 AppContainer ）的空间内，距上左右边框距离为 2 ，距下边框距离为 23 （状态栏会占据这高度为 23 的空间）。
c) 89 行根据上面定义的元素间的位置关系对元素进行排列。
d) 91 、 92 行注册了 FUSION_INITIALIZED 和 FUSION_ERROR 两个事件，这样当 Fusion 框架初始化完毕时就会调用 fusionInitialized 函数，出错时会调用 fusionError 函数
e) 93 行就是我们等待已久的“电源”功能，这个函数会启动 Fusion 框架，然后会由 Fusion 完成解析网页布局定义、加载小工具与地图等其余功能。
在 143-193 行是各个页面元素间的嵌套关系，这个关系跟初始化中的初始化元素代码一起，完成了对元素间位置关系的定义。
既然网页模板定义了各元素之间的关系，那么，又是由谁来确定小工具被放置在哪个元素中呢？答案是，网页布局定义文件。
网页布局定义文件，是放置在 MapGuide 服务器上的一个 XML 资源文件。一般来说，网页布局定义文件是根据 MapGuide 配置工具（如 Autodesk MapGuide Studio ）根据小工具信息文件、模板说明信息、默认应用程序定义文件以及用户的操作，最后生成的文件。
虽然灵活网页布局与基本网页布局在格式上有所不同，但两者的作用基本相同，那就是决定每个界面元素包含什么内容。
代码 3-3 是 MapGuide 示例资源中灵活网页布局配置文件“ Library://Samples/Sheboygan/FlexibleLayouts/Slate.ApplicationDefinition ”的片段。
代码 3-3 一个典型的复杂网页布局片段
我们可以看出，一个灵活网页布局主要由一个地图集合于一个小工具集合构成，地图集合里面是当前网页中将要用到的地图，而小工具集合用于定义其中的小工具。
小工具集合分为三个部分： Container 、 MapWidget 和 Widget 。 Widget 节点包含的是网页布局中用到的除地图小工具外所有小工具的配置信息。 MapWidget 是地图小工具的信息。这似乎都容易理解，那么 Container 里面的内容是什么呢？
在 Fusion 中，如果要修改一个元素的排列位置，就需要改动网页模板文件。但大部分情况下，用户不希望仅仅为了增加一个按钮小工具就要改动网页。为了解决这个问题， Fusion 使用了“容器”这一概念。容器中可以包含若干小工具，容器自己负责维护其容纳的小工具的位置关系（有点类似于 Java 或者 .net 中的“布局”（ Layout ）这一概念）。容器做为页面的元素，其与其他元素的位置关系由网页模板确定。而容器内包含哪些小工具，就由网页布局定义文件中的 Container 节点负责定义。比如上面代码中， Toolbar 容器内就包含 RefreshMap 等小工具。
经过上面的介绍，您已经基本明白了 Fusion 框架的基本原理，以及小工具、网页布局是如何被定义的。下面就请随我一起，进入到 Fusion 的基础平台中，看看基础平台是如何为小工具们提供了如此强大的功能的。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
