DSF view Model

View Model是指理想的用户可呈现的数据结构，这与data Model形成了对比，data Model指的是自然的数据结构，尽管两者最终往往是相同的，用户表示的需求经常会发生变化，因此view model的中心特性能够对其进行自定义
1.Flexible Hierarchy（灵活的层次结构）
ViewModel基于调试平台团队在3.2中引入了Flexible Hierarchy API。Flexible Hierarchy API有几个显著的特性：

• viewer中数据表示的各个方面（content，label，column）都有提供程序接口
• viewer为viewer中每个元素检索提供程序接口，这允许从多个源填充视图内容。
• 提供程序接口是异步的。
  注意：Flexible Hierarchy在Eclipse平台3.4中仍然是一个临时API。这实际上保证了DSF将在将来的版本中打破向后API兼容性。然而，这些API现在已经被DD和CDT等开源项目以及许多商业Eclipse集成广泛使用，因此API的变化可能很小，而且主要与打包有关。
  2.The Adapter Problem
  Flexible Hierarchy API的第二个特性是使用适配器模式实现的。适配器模式的一个向下侧是，只能有一个为给定元素注册的特定类型的适配器实例。对于灵活的层次结构提供程序，这意味着每个提供者必须为元素出现在的每个视图实现元素表示逻辑，因此添加新视图可能会强制更改大量模块。

注意：适配器问题带来的限制可以通过Flexible Hierarchy API的标准调试模型实现得到最好的观察。如果开发人员希望扩展Java调试器，为Java堆栈框架提供自定义标签提供程序，那么该开发人员就必须扩展Java堆栈框架对象，以便为其注册新的标签提供程序。
3.Model Proxy Problem
实现Flexible Hierarchy API还有第二个主要挑战，它源于Content Provider和Model Proxy对象的不同生命周期。

• Content Provider的生命周期由模型管理。viewer分别为每个element请求对Content Provider程序的引用，而Content Provider的实例可以是静态对象，也可以是每个请求的新创建对象，也可以是元素本身。

• Model Proxy是通过IModelProxyFactory适配器创建的，它由viewer根据需要实例化和释放。

一般来说，这种安排意味着Content Provider和Model Proxy是使用单独的对象实现的。但是，这两个对象都需要了解视图中元素的布局，才能正常工作。
4.View Model Design
DSF View Model是一个对象集合，它从Data Model中检索信息，并使用该信息填充一个或多个Flexible Hierarchy viewers的内容。

注：DSF View Model可用于表示任何数据模型。DSF数据模型中有一些特性使得使用视图模型更容易表示它，但是这些特性并不是严格必要的。
当处理来自Flexible Hierarchy Viewers的适配器请求时，view model使用四种类型的元素：

• VM Adapter：adapter是view model hierarchy的顶级对象，来自viewer的所有内容更新都由vm adapter的单个实例处理。VM adapter根据update对象中包含的表示上下文将这些更新的处理委托给相应的VM提供程序。

• VM Provider ：提供程序管理单个视图的内容。它根据update对象中元素的树路径，将内容请求委托给相应的VM节点

• VM Node：VM节点允许对视图中类似的元素进行分组。此类节点的示例有：threads节点、stack frames节点、variables节点等。VM节点创建VM上下文对象来表示数据模型中的数据元素。

• VM Context：VM Context对象用于填充查看器的内容。给定的VM上下文可能包含对数据模型中某个元素的引用（例如，堆栈帧或变量），也可能仅用于表示目的（例如，Expressions视图中的“addnewexpression”条目）。
  
  注意：DSF view model设计最重要的特性是它如何克服适配器问题。VM context用于将getAdapter（）请求从查看器重定向到相应的对象。通过这种方式，一个特定的视图可以有许多不同的视图模型表示，而不是只有一个。
  5.Layout Customization（布局再定义）
  视图模型的主要设计目标是使在查看器中自定义给定数据模型的布局和其他表示方面变得更容易。解释这种定制的最简单方法是使用一个示例。
  Timer Data Model
  在前面描述的计时器示例中，其数据模型中有三种类型的元素：

  • Timers-计时器的值每秒递增。这些元素独立于任何其他元素。

  • Triggers-触发器具有由用户指定的常量值。

  • Alarms-报警表示一个定时器和一个触发器的组合，每个定时器和触发器的组合都有一个单独的报警对象。警报有一个状态，即已触发或未触发。
    
    Timers View Model
    在tree hierarchy的视图中显示时，timers或triggers都可以显示为顶级元素。在视图模型中，布局配置由给定VM提供程序中VM节点的配置控制。这个配置可以很容易地更改，就像在定时器示例中所做的那样（参见下图）。
    

6. Event Handling（事件处理）
   view model的另一项重要工作是将源于Data model的事件转换为通用事件（模型增量），查看器可以使用这些事件来更新自身。这些模型增量是对查看器中哪些元素发生了变化以及这些元素发生了什么变化的低级描述。对查看器的某些更新甚至需要更改的元素的完整路径，包括路径中每个元素的索引和子元素数。
   Event handling in VM Provider
   VM Provider是一个在viewmodel中监听data model事件的对象，事件按下面的步骤处理

• VM Provider从Data Model接收vent（出口）
• VM Provider为每个node调用IVMNode.getDeltaFlags() ，来确定是否需要为给定事件生成模型增量
• 如果需要一个delta（增量），VM Provider为每个node调用IVMNode.buildDelta() ，在节点层次结构中构建增量
• 调用所有节点后，将完成的增量发送给查看器，以便查看器可以自我刷新。
  
  Processing events in TimersVMNode

org.eclipse.cdt.examples.dsf.timers.TimersVMNode

141:     public int getDeltaFlags(Object e) {
   
142:         // Th