时间戳

首页 > 解决方案 > 为什么 xforms-select 和 xforms-deselect 元素会冒泡？

events - 为什么 xforms-select 和 xforms-deselect 元素会冒泡？

问题描述

根据XForms 规范，大多数事件都被称为“冒泡”。

根据DOM 级别 2 事件规范，“冒泡”事件意味着与事件调度目标的祖先元素相关联的此事件的处理程序也将接收此事件。

对于要指定为“气泡”的事件，这意味着 xf:dispatch 操作无法修改气泡行为以将其限制为目标。

我不明白这么多 xforms 事件冒泡有什么好处。例如，xforms-select 和 xforms-deselect。它们适用于 xf:item（属于 xf:select*）和 xf:case（属于 xf:switch，即在带有制表符的表单中使用）。

假设我有一个带有 xforms-select 处理程序的 xf:case，它将导致刷新昂贵的渲染小部件，只是在实际选择选项卡时而不是每次更新模型时。现在我在同一个选项卡中也有一个 xf:select 。现在，每当用户在该选择中选择另一个项目时，xf:case 都会在冒泡阶段收到 xforms-select，每次都执行代价高昂的更新操作。

这似乎没有意义。

事实上 xforms-node-attached 是正确的：我们真的想具体说明哪个表单元素附加了节点。但除此之外，据说大多数事件都是冒泡的。

如果我理解了这个问题的原因，我可以更好地适应这个问题。否则，我很想更改我的 XForms 引擎以更改 xforms-select 和 xforms-deselect 的定义，以免冒泡。

标签： eventsdomxforms

解决方案

这是为了允许所谓的事件委托：

“事件委托是指使用事件传播（冒泡）在 DOM 中处理比事件起源的元素更高级别的事件的过程。它允许我们为现在或在未来。” （来自此 jQuery 文档页面的旧版本）

一般来说，这是一件好事：

  • 您使用较少的事件侦听器。
  • 一个监听器可以监听多个目标。
  • 您不需要删除/添加侦听器，因为添加/删除了 DOM 元素。

似乎，在 HTML 世界中，事情已经朝着让一切都冒泡的方向发展。例如，旧focus事件没有冒泡，而新focusin事件冒泡。

如果您有一个事件处理程序，它被分派到多个目标的事件激活，在某些情况下，您需要区分的能力。这是事件上下文信息有用的地方。像 jQuery 这样的库还允许您关联一个由 CSS 选择器过滤的事件处理程序，这很简洁。

现在，xforms-select具体来说，您的问题是您无法区分发送到 anxf:case和 an 的此事件xf:select。这可能意味着 XForms 不应该为这两个场景提供一个事件，或者它应该有足够的事件上下文信息来区分这两者。我不认为这是不让事件冒泡的理由。

推荐阅读