2012-06-02 49 views
4

用户界面通常由不同的输入设备组成,如按钮,输入栏,对话框,滑块等。事件顺序通常决定了预期的行为,并且这种行为通常不容易在简单的规则中发现。如何在模块化用户界面中管理基于事件的输入?

是否有这种类型的问题的通用方法?

作为一个界面变得如此简单的例子,可以使用一个带有3个切换按钮的界面。如果按钮点击的行为取决于每个按钮的状态,则可以使用2^3 * 3 = 24个事件情况。如果行为还取决于事件历史记录,则事件案例的数量呈指数增长。

作为一个现实生活中的例子,看看我正在使用的wysiwyg文本编辑器。我选择编辑器上的焦点/模糊事件来启用/禁用编辑器。有些按钮(小部件)会立即将焦点返回到编辑器,而其他按钮会打开一个对话框。在下面的图片中,显示点击界面元素时焦点的位置。

我发现管理焦点是一个棘手的问题,通常会引入不需要的或反直觉的行为。

user interface sketch

+0

@Sagiv现在,该对话框具有打开和关闭的事件处理程序,它将焦点返回到#txt(默认行为)。在(2)的情况下,该对话框还具有由编辑调用的公共功能。在这里我设置了一个防止默认行为的标志。它可以工作,但我不希望有对话框的新插件必须实现相同的功能,同时我想给予自由让他们拥有自己的功能(例如,针对不同CMS解决方案的图像上传) –

+0

研究BackboneJS,这对于在UI中控制和共享事件非常有用。 – AlienWebguy

+0

@AlienWebguy。我最近学习了骨干,而且做得很好。但据我看来,这并不能解决我的前三个子弹。 (也许我们的评论是在我更新我的问题之前发布的,所以没有冒犯) –

回答

1

获得我的问题权利是答案的一部分。我的问题是关于一个特殊情况,其中小部件不仅仅是数据的表示,而是用于共享信息的输入设备。

正如Matteo Migliore所建议的,事件分派器具有不同的用途。在信息流更加线性的情况下,它是有用的:一方面是一个或多个可以触发事件的对象,另一方是监听这些事件的对象。

就我而言,不仅应该集中管理事件,更重要的是管理逻辑。这种逻辑的特点是几个执行器影响相同的数据源,可能会导致循环。在我的情况下,这个数据源是:重点在哪里,编辑器何时启用/停用。

防止循环的解决方案是使用内部状态变量并仔细设计将每个状态+事件组合转换为动作+新状态的映射。基本实现可能看起来像:

switch (eventdescription) { 
    case 'click_in_txt': 
    switch (state) { 
     case 'inactive': 
     activate(); 
     state = 'active'; 
     break; 
     case 'plugin_has_focus'; 
     close_plugin(); 
     state = 'active' 
     break; 
     default: 
     console.log('undefined situation ' + state + '/' + eventdescription); 
    } 
    ... 
} 

这种方法仍然需要一些试验和错误,但很容易地看到哪些情况会导致一个错误,然后你可以单独改变行为这种情况。此外,console.log()函数还显示您忽略了可能导致意外行为的某些事件组合的位置。

decision table for events/state

2

可以使用Mediator AKA Message Broker的模式来解耦UI组件(通常任何类型的应用程序组件),这里的两篇文章吧:

  1. Mediator Pattern applied to Javascript
  2. Mediator pattern javascript
+0

我不确定,因为在我的情况下,我有一个中心对象,即编辑器,它可能已经可以管理所有事件。我的问题仅仅是让所有的事件在整个系统的不同状态下都能正常工作,并不是所有信息都是可用的(例如,在#text上触发模糊事件时,甚至不清楚(mousedown-> mouseup->点击) –

+0

你的回答激励我与我自己一起来,所以为你+1! –

+0

伟大的:),发送消息是揭示函数的最好方法一个不知道外壳是如何组成的UI组件。 –

0

最通用的方法,我可以想像,是画事件树。此事件树的单一领域的通用表示是这样的:

(start state) -> [event] -> <action> -> [event] -> <action> ... 

因为不同的事件,在每个点都是可能的,事件树呈指数增长的时间越长,观察到的分支。幸运的是,界面经常会回到过去的状态,例如关闭对话框后,它将返回到开始状态。

查找和建模这些返回状态是一个创建过程,对每个应用程序都是唯一的。命名这些状态是有帮助的。中间结果是上面描绘的状态/事件/动作图。

相关问题