随着OperaMasks 2.2正式版的发布与OperaMasks.org新网站的上线，对OperaMasks后续版本的规划也密锣紧鼓地展开。无规矩则不成方圆，在进行细化的功能规划之前，在这里我们先基于OperaMasks发展两年多来的经验教训，总结出项目后续发展的一些指导原则和目标：

开源不是OperaMasks产品的生命力

       一直以来，我们对Operamasks的定位是："一个开源的Web开发解决方案"。开源，是金蝶中间件有限公司努力撬动民族软件产业发展的支点，是一个让有志者集思广益展现技术能力的平台，是用户放心使用的保证。开源为OperaMasks社区带来了生命力。但开源归根结底是项目运作、产品发布的一种策略，开源并不应该成为OperaMasks产品的生命力。开源免费，不能成为降低产品质量与支持水准的借口，也绝不会是用户选用AOM的唯一原因。OperaMasks作为一个严肃的开发框架产品，它的产品生命力体现在能为用户带来实际的价值，。

EXT-JS不是OperaMasks产品的生命力

       OperaMasks的许多构件基于Ext-JS渲染，拥有和EXT-JS一致的样式、风格与外观。诚然，EXT-JS简化了AOM的渲染行为，其精美的样式与交互能力增加了用户的接受程度。但EXT-JS归根结底是AOM渲染中所使用的第三方库，也并不应该成为OperaMasks产品的生命力。这体现在：首先，OperaMasks引擎的设计目的不是为了简化EXT-JS。OperaMasks有其自身的不依赖于EXT-JS的编程模型，虽然OperaMasks本身不会阻止用户直接使用EXT-JS技术在浏览器端编程（甚至为这类用户提供了方便），达到更为细致的定制效果。但我们不应该把这种方式作为解决OperaMasks自身问题的推荐方式。其次，OperaMasks构件库的设计目的不是为了对EXT-JS的构件进行简单的封装。构件库中需要有什么构件，构件需要有什么属性，此类决定应该基于实际的需求进行抽象得出结论，而不是照搬EXT-JS的构件模型。

真正生命力

  OperaMasks的真正生命力在于：提供了一种新的、完整的Web编程模型。这种编程模型是：

• 基于构件的；（对C/S编程模型的一种继承）
• 事件驱动的；（客户端与服务器端编程的融合）
• IoVC的；（一种架构方法上的创新，对MVC分离能力的改进）
• 基于J2EE的；（对J2EE已有技术如jsp/servlet/spring/hibernate的继承）
• IDE支持的。（对RAD的继承）

 为了体现这种"新的、完整的Web编程模型"，AOM主要提供了

• 一种站在JSF之上，并提供丰富AJAX特性的运行期引擎；
• 一套较完整的富客户端构件库。其中包括了一部分基于EXT-JS渲染的构件
• 一个基于Eclipse的集成式开发环境OperaMasks Studio

 同时，通过两年多的推广、支持与客户反馈，我们获得了许许多多深刻的认识，在这里总结为几点原则：

• 既然我们提供了比较丰富的构件库，那就意味着我们必须维护这些构件库能够正常的工作
• 既然我们永远无法提供满足所有人、所有场景下的构件，那就意味着我们必须开放足够的API，以便允许用户进行构件的扩充
• 即然我们要允许用户进行构件的扩充，这就意味着我们有一个建壮的、功能丰富的、可扩展的引擎

这就意味着

OperaMasks的RoadMap

2.3版本:2009年8月底

主题：已有构件的稳定性、引擎的建壮性、引擎功能的丰富性