是否可以使用dojo工具包的dnd api更改头像的位置?此时,拖动时,被拖动项的头像出现在鼠标光标的右下方。我希望它与鼠标光标位于同一位置。我对我的应用程序进行了一些可用性测试,大多数人似乎试图尝试将头像拖到放置区域,而不是将光标移动到放置区域上。任何输入都会很好。谢谢!
1 回答
抱歉,由于技术原因无法实现。
更新:根据大众的要求,这些是技术原因:
- 当鼠标正下方有一个节点时,该节点会获取所有鼠标事件。
- 鼠标事件在父链中冒泡。
- 现在想象你用鼠标移动这个节点——这个节点总是会得到所有的鼠标事件。
- 这意味着任何其他节点,例如,目标不能获得鼠标事件,除非它是移动节点的父节点。通常情况并非如此。
但我知道其他人可以做到!这应该是可能的!是的,有可能……原则上:
- 让我们注册所有目标节点。
- 让我们直接在最顶层的父级(文档)上捕获相关的鼠标移动事件。
- 当我们检测到拖动操作时,让我们执行以下操作:
- 计算所有目标的几何形状(边界框)。
- 在每次鼠标移动时,让我们检查当前鼠标位置是否与目标重叠。“A+”学生的加分点:检测与其他节点的重叠,例如,当目标因美观原因部分模糊时,并正确处理这种情况。
- 如果当前鼠标位置与目标重叠,让我们启动“可以放下”动作,例如,显示一些提示以便最终用户知道她现在可以放下。
为什么 Dojo 不这样做?由于一些技术原因(我们终于到了那里!):
- 在大多数浏览器中,节点的几何计算是出了名的错误。一旦涉及表格或任何其他重要的放置方式,您就不能 100% 确定边界框是正确的。
- 几何计算是一项昂贵的操作,我们必须对所有目标的每次拖动操作至少执行一次,假设在拖动操作期间不能进行任何更改(并非总是如此)。浏览器可能出于多种原因重排节点⇒它可以移动/调整现有目标的大小,因此我们必须保持警惕。
- 通常计算的框保存在一个列表中⇒检查交叉点列表是O(n)(线性)⇒随着目标数量的增加不能很好地扩展。
- 所有鼠标事件处理程序都应该很快,否则浏览器的鼠标事件处理工具可能会“损坏”,从而导致不可预知的副作用。有关鼠标事件处理速度缓慢的原因,请参阅前面的几点。
- 改进线性搜索是可能的,例如,可以使用 2D 空间树,但它会导致更多(更多)JavaScript 代码⇒ 在客户端下载更多内容⇒ 通常不值得。
我怎么知道?因为 Dojo 在早期版本中曾经有过这种拖放,而且我们对上面描述的战斗问题感到厌烦。任何改进都是一场艰苦的战斗,这增加了代码大小。最后,我们决定不重新发明和复制浏览器中已经内置的机制。浏览器实际上做同样的工作:计算节点的几何形状,找到底层节点,并适当地调度鼠标移动事件。
当前的实现不使用鼠标移动事件并且不计算几何。相反,它依赖于在开始拖动后目标检测到的鼠标悬停/移出事件。它工作可靠并且扩展性很好。
Another wrinkle in this story: Dojo treats targets as containers — a very common use case (shopping carts, rearranging items, editing hierarchies). Linear containers and generic trees are implemented at the moment, custom containers are possible. When dragging and dropping you can see and drop dragged items in a proper position within a target container, e.g., inserting them between existing items. Implementing this feature using geometric calculations and checks would be prohibitively expensive.