大师兄

31 | 辅助界面元素的架构设计

你好，我是七牛云许式伟。

我们第二章 “桌面软件开发” 今天开始进入尾声。前面我们主要围绕一个完整的桌面应用程序，从单机到 B/S 结构，我们的系统架构应该如何考虑。并且，我们通过五讲的 “画图” 程序实战，来验证我们的架构设计思路。

这个实战有点复杂。对于编码量不多的初学者，理解起来还是有点复杂性的。为了减轻理解的难度，我们从原计划的上下两讲，扩大到了五讲。尽管如此，理解上的难度仍然还是有的，后面我们做总结时，会给出一个不基于 MVC 架构的实现代码。

今天我们不谈桌面应用的架构，而是来谈谈辅助界面元素的架构设计。

辅助界面元素非常常见，它其实就是通用控件，或者我们自定义的控件。例如在我们画图程序中使用了线型选择控件（menu.js#L105），如下：

<select id="lineWidth" onchange="onIntPropChanged('lineWidth')">
      <option value="1">1</option>
      <option value="3">3</option>
      <option value="5">5</option>
      <option value="7">7</option>
      <option value="9">9</option>
      <option value="11">11</option>
    </select>

还有颜色选择控件（menu.js#L115），如下：

<select id="lineColor" onchange="onPropChanged('lineColor')">
      <option value="black">black</option>
      <option value="red">red</option>
      <option value="blue">blue</option>
      <option value="green">green</option>
      <option value="yellow">yellow</option>
      <option value="gray">gray</option>
    </select>
    
    <select id="fillColor" onchange="onPropChanged('fillColor')">
      <option value="white">white</option>
      <option value="null">transparent</option>
      <option value="black">black</option>
      <option value="red">red</option>
      <option value="blue">blue</option>
      <option value="green">green</option>
      <option value="yellow">yellow</option>
      <option value="gray">gray</option>
    </select>

我们统一用通用的 select 控件实现了一个线型选择器、两个颜色选择器的实例。虽然这种方式实现的颜色选择器不够美观，但是它们的确可以正常工作。

不过，产品经理很快就提出反对意见，说我们需要更加用户友好的界面。赶紧换一个更加可视化的颜色选择器吧？比如像下图这样的：

辅助界面元素的框架

怎么做到？

我们不妨把上面基础版本的线型选择器、颜色选择器叫做 BaseLineWidthPicker、BaseColorPicker，我们总结它们在画图程序中的使用接口如下：

我们解释一下这个表格中的各项内容。

id 是控件的 id，通过它可以获取到辅助界面元素的顶层结点。

value 是界面元素的值，其实也就是辅助界面元素的 Model 层的数据。从 MVC 架构角度来说，Model 层的数据一般是一棵 DOM 树。但是对很多辅助界面元素来说，它的 DOM 树比较简单，只是一个数值。比如线型选择器是一个 number，颜色选择器是一个 Color 值。

palette 是颜色选择器的调色板，用来指示颜色选择器可以选择哪些颜色。

blur() 方法是主动让一个界面元素失去焦点。

onchange 事件是在该界面元素的值（value）通过用户界面交互进行改变时发送的事件。需要注意的是，这个事件只在用户交互时发送。直接调用 element.value = xxx 这样的方式来修改界面元素的值是不会触发 onchange 事件的。

为了便于修改辅助界面元素，我们计划引入统一的辅助界面元素的框架。

这个框架长什么样？

首先，每个界面元素使用的时候，统一以 <div type="xxx">来表示。比如上面的一个线型选择器、两个颜色选择器的实例可以这样来表示：

<div type="BaseLineWidthPicker" id="lineWidth" onchange="onIntPropChanged('lineWidth')"></div>
    
    <div type="BaseColorPicker" id="lineColor" onchange="onPropChanged('lineColor')" palette="black,red,blue,green,yellow,gray"></div>
    
    <div type="BaseColorPicker" id="fillColor" onchange="onPropChanged('fillColor')" palette="white,null(transparent),black,red,blue,green,yellow,gray"></div>

那么它是怎么被替换成前面的界面元素的？

我们引入一个全局的 qcontrols: QControls 实例，所有我们定义的控件都向它注册（register）自己。注册的代码如下：

class QControls {
      constructor() {
        this.data = {}
      }
      register(type, control) {
        this.data[type] = control
      }
    }

可以看出，注册的逻辑基本上没做什么，只是建立了类型（type）和控件的构建函数（control）的关联。有了这个关联表，我们就可以在适当的时候，把所有的 <div type="xxx">的div 替换为实际的控件。替换过程如下：

class QControls {
      init() {
        let divs = document.getElementsByTagName("div")
        let n = divs.length
        for (let i = n-1; i >= 0; i--) {
          let div = divs[i]
          let type = div.getAttribute("type")
          if (type != null) {
            let control = this.data[type]
            if (control) {
              control(div)
            }
          }
        }
      }
    }

这段代码逻辑很简单，遍历文档中所有的 div，如果带 type 属性，就去查这个 type 有没有注册过，注册过就用注册时指定的构建函数去构建控件实例。

完整的辅助界面元素框架代码如下：

具体构建控件的代码是怎么样的？源代码请参考这两个文件：

我们拿 BaseColorPicker 作为例子看下吧：

function BaseColorPicker(div) {
      let id = div.id
      let onchange = div.onchange
      let palette = div.getAttribute("palette")
      let colors = palette.split(",")
      let options = []
      for (let i in colors) {
        let color = colors[i]
        let n = color.length
        if (color.charAt(n-1) == ")") {
          let offset = color.indexOf("(")
          options.push(`<option value="` + color.substring(0, offset) + `">` + color.substring(offset+1, n-1) + `</option>`)
        } else {
          options.push(`<option value="` + color + `">` + color + `</option>`)
        }
      }
      div.outerHTML = `<select id="` + id + `">` + options.join("") + `</select>`
      let elem = document.getElementById(id)
      if (onchange) {
        elem.onchange = onchange
      }
    }
    
    qcontrols.register("BaseColorPicker", BaseColorPicker)

可以看到，构建函数的代码大体分为如下三步。

第一步，从占位的 div 元素中读入所有的输入参数。这里是 id, onchange, palette。

第二步，把占位的 div 元素替换为实际的界面。也就是 div.outerHTML = xxx 这段代码。

第三步，如果用户对 onchange 事件感兴趣，把 onchange 响应函数安装到实际界面的 onchange 事件中。

jQuery 颜色选择器

接下来我们就开始考虑替换颜色选择器的实现了。新版本的颜色选择器，我们不妨命名为 ColorPicker。这个新版本的使用姿势必须和 BaseColorPicker 一样，也就是：

从使用的角度来说，我们只需要把之前的 BaseColorPicker 换成 ColorPicker。如下：

<div type="BaseLineWidthPicker" id="lineWidth" onchange="onIntPropChanged('lineWidth')"></div>
    
    <div type="ColorPicker" id="lineColor" onchange="onPropChanged('lineColor')" palette="black,red,blue,green,yellow,gray"></div>
    
    <div type="ColorPicker" id="fillColor" onchange="onPropChanged('fillColor')" palette="white,null(transparent),black,red,blue,green,yellow,gray"></div>

那么实现方面呢？

我们决定基于 jQuery 社区的 spectrum 颜色选择器。

我们的画图程序的主体并没有引用任何现成的框架代码。jQuery 是第一个被引入的。

对待 jQuery，我们可以有两种态度。一种是认为 jQuery 设计非常优良，我们很喜欢，决定将其作为团队的编程用的基础框架。

在这种态度下，我们允许 jQuery 风格的代码蔓延得到处都是，典型表现就是满屏皆是 $ 符号。

当然这种选择的风险是不低的。有一天我们不想再基于 jQuery 开发了，这意味着大量的模块需要进行调整，尤其是那些活跃的项目。

另一种态度是，认为 jQuery 并不是我们的主体框架，只是因为我们有些模块用了社区的成果，比如 spectrum 颜色选择器，它是基于 jQuery 实现的。这意味着我们要用 spectrum，就需要引入 jQuery。

这种团队下，我们会尽可能限制 jQuery 的使用范围，尽量不要让它的代码蔓延，而只是限制在颜色选择器等少量场景中。

我们这一讲假设我们的态度是后者。我们有自己的基础开发框架（虽然我们其实基本上接近裸写 JavaScript 的状态），所以不会大面积使用 jQuery。

这样我们需要包装 jQuery 组件。代码如下（参阅 controls/ColorPicker.js）：

function ColorPicker(div) {
      let id = div.id
      let onchange = div.onchange
      let palette = div.getAttribute("palette")
      let colors = palette.split(",")
      let value = colors[0]
      div.outerHTML = `<input type="button" id="` + id + `" value="` + value + `">`
      let elem = $("#" + id)
      elem.spectrum({
        showInitial: true,
        showInput: true,
        showButtons: true,
        preferredFormat: "hex6"
      })
      if (onchange) {
        elem.change(onchange)
      }
      Object.defineProperty(document.getElementById(id), "value", {
        get() {
          return value
        },
        set(x) {
          if (this.busy) {
            return
          }
          value = x
          this.busy = true
          elem.spectrum("set", value)
          this.busy = false
        }
      })
    }
    
    qcontrols.register("ColorPicker", ColorPicker)

这里大部分代码比较常规，只有 Object.defineProperty 这一段看起来比较古怪一些。这段代码是在改写 document.getElementById(id) 这个界面元素的 value 属性的读写（get/set）函数。

为什么需要改写？

因为我们希望感知到使用者对 value 的改写。正常我们可能认为接管 onchange 就可以了，但是实际上 element.value = xxx 这样的属性改写是不会触发 onchange 事件的。所以我们只能从改写 value 属性的 set 函数来做。

set 函数收到 value 被改写后，会调用 elem.spectrum("set", value) 来改变 spectrum 颜色控件的当前值。

但这里又有个细节问题：elem.spectrum("set", value) 内部又会调用 element.value = value 来修改 document.getElementById(id) 这个界面元素的 value 属性，这样就出现了死循环。怎么办？我们通过引入一个 busy 标志来解决：如果当前已经处于 value 属性的 set 函数，就直接返回。

辅助界面元素的架构设计

到目前为止，我们实现了三个符合我们定义的控件规范的辅助界面元素。如下：

观察这些辅助界面元素的代码，你会发现它们都没有基于 MVC 架构。

是因为辅助界面元素不适合用 MVC 架构来编写么？

当然不是。

更本质的原因是因为它们规模太小了。这些界面元素的特点是 DOM 都是一个 value，并不是一棵树，这样 Model 层就没什么代码了。同样的逻辑，View 层、Control 层代码量都过于短小，就没必要有那么清楚的模块划分。View 负责界面呈现，Control 负责事件响应，只是在心里有谱就好了。

但并不是所有辅助界面元素都这么简单。

举一个简单的例子。让我们给自己设定一个新目标：把我们前面实战的 “画图” 程序，改造成一个标准的辅助界面元素，这可行么？

答案当然是肯定的。

但是这意味着我们有一些假设需要修正。这些假设通常都和唯一性有关。

比如，全局有唯一的 View 对象实例 qview: QPaintView。如果我们是辅助界面元素，意味着我们可能在同一个界面出现多个实例。在多实例的情况下，View 对象显然就应该有多个。

再比如，我们画图程序的辅助界面元素（参见 accel/menu.js）都是单例，具体表现为这些界面元素的 id 都是固定的。

当然，辅助界面元素的改造方案有多种可能性。一种方案是将辅助界面元素也改造为多例，使得每个 QPaint 实例都有自己的辅助界面元素。

另一种方案是继续保持单例，这意味着多个 QPaint 实例会有一个当前实例的概念。辅助界面元素根据场景，可以是操作全部实例，也可以是操作当前实例。

我们选择继续保持单例。这意味着 qview: QPaintView 这个全局变量可以继续存在，但是和之前的含义有了很大不同。之前 qview 代表的是单例，现在 qview 代表的是当前实例。

有了当前实例当然就有切换。这样就需要增加焦点相关的事件响应。

在画图程序中，很多 Controller 都是 View 实例相关的。比如：PathCreator、ShapeSelector 等。在 View 存在多例的情况下，这些 Controller 之前的 registerController 动作就需要重新考虑。

为了支持多例，我们引入了 onViewAdded、onCurrentViewChanged 事件。当一个新的 View 实例被创建时，会发送 onViewAdded 事件。Controller 可以响应该事件去完成 registerController 动作。如下：

onViewAdded(function(view) {
      view.registerController("PathCreator", function() {
        return new QPathCreator(view, false)
      })
    })

原先，当前图形样式是放在 View 中的，通过 qview.style 可以访问到。这会导致多个 View 实例的当前图形样式不一样，但是我们辅助界面元素又是单例的，这就非常让人混淆。最后我们决定把 qview.style 挪到全局，改名叫 defaultStyle（参阅 accel/menu.js#L42）。

做完这些改造，我们的画图程序就有了成为一个标准控件的基础。具体代码如下（参阅 PaintView.js）：

function newPaintView(drawingID) {
      let view = new QPaintView(drawingID)
      fireViewAdded(view)
      return view
    }
    
    function initPaintView(drawingID) {
      let view = newPaintView(drawingID)
      setCurrentView(view)
    }
    
    function PaintView(div) {
      let id = div.id
      let width = div.getAttribute("width")
      let height = div.getAttribute("height")
      div.outerHTML = `<canvas id="` + id + `" width="` + width + `" height="` + height + `">你的浏览器不支持Canvas！</canvas>`
      initPaintView(id)
    }
    
    qcontrols.register("PaintView", PaintView)

有了这个 PaintView 控件，我们就可以到处引用它了。我们做了一个 PaintView 控件的 DEMO 程序，它效果看起来是这样的（代码参阅 PaintDemo.htm）：

从这个截图看，细心的你可能会留意到，还有一个问题是没有被修改的，那就是 URL 地址。我们的 QPaintView 在 load 文档后会修改 URL，这作为应用程序并没有问题。但是如果是一个控件，整个界面有好多个 PaintView，URL 中应该显示哪个文档的 ID？

显然谁都不合适。如果非要显示，可能要在 PaintView 实例附近放一个辅助界面元素来显示它。

怎么修改？

这个问题暂且留给大家。

结语

今天探讨了辅助界面元素，或者叫控件的架构设计。从大的实现逻辑来说，它和应用程序不应该有本质的不同。但控件总是要考虑支持多实例，这会带来一些细节上的差异。

支持多实例听起来是一项简单的工作，但是从我的观察看，对很多工程师来说实际上并不简单。不少初级工程师写代码往往容易全局变量满天飞，模块之间相互传递信息不假思索地基于全局变量来完成。这些不良习惯会导致代码极难控件化。

当然我们不见得什么桌面应用程序都要考虑把它控件化。但是我们花一些精力去思考控件化的话，会有助于你对架构设计中的一些决策提供帮助。

当然更重要的，其实是让你有机会形成更好的架构设计规范。

这一讲我们作出的修改如下：

这是最新版本的源代码：

如果你对今天的内容有什么思考与解读，欢迎给我留言，我们一起讨论。下一讲我们会谈谈架构设计的第二步：如何做好系统架构。

如果你觉得有所收获，也欢迎把文章分享给你的朋友。感谢你的收听，我们下期再见。

在 GitHub 上编辑此页2023/9/29 14:47:35