在Adobe OpenScreen项目的推进，FP10在越来越多的设备上得到支持，从Windows Mobile, Google’s Android, Nokia S60 / Symbian/Palm，甚至到ARM的智能设备；这就要求Flash应用具有更多的适应性来适应不同的设备，尤其是屏幕大小不同产生的动态GUI的情景；这篇文章针对这种情形设计了一种被动多视图设计模式，来解决不同屏幕分辨率情况下动态界面创建的问题，而使其业务逻辑不受影响。

被动视图模式来源于模型－视图－表演者模式（MVP），MVP模式也被认为来自经典的MVC模式，被动视图模式跟“代码后置”实现有些类似，因为他们都实现了AS逻辑和MXML/AS组件的完全分离；被动视图模式允许我们容易测试应用，因为我们可以仅仅为逻辑创建测试用例，或者仅仅为视图创建测试用例。

这里的视图特征有：

1. 视图中的状态；
2. 视图是被动的而且不知道表演者的存在；

这里的表演者特征有：

1. 包含业务逻辑；
2. 观察视图事件；
3. 使用视图中的组件；
4. 保持数据或者数据类的引用；

通过将视图中的逻辑移出去，被动视图模式可以获得设计者和开发者工作的分离，从而形成一种范例：在此情况下很容易改变视图！
视图类只包含组件和他们的状态，没有事件、逻辑、改变或者模型，这种模式与Flash Catalyst结合完美，因为设计师的责任师创建视图和状态（state），因此你可以拷贝/粘贴FXG代码到你的应用中，仅设置下每个组件的ID就可以了。

编者点评：这种模式看起来很新颖，但是仔细研究发现跟PureMVC结构很类似，presenter的角色跟mediator的角色很类似，他的creator类似于PureMVC中的facade，但是框架中每个主类比如Presenter都有个子类在里面看起来不太习惯，感觉更像是一个另类的PureMVC，相比之下presenter的名称似乎又跟表现层混合在了一起；如果真要谈到适配Flash Catalyst工作流，我倒是认为这篇文章是个不错的例子。