Difference between revisions of "Zh/Documentation/DevGuide/ProUNO/Component Context"

Latest revision as of 17:22, 4 July 2018

前面将服务管理器描述为主要工厂，它被传送到每个新实例化的组件。部署应用程序后，一个组件通常需要更多可以交换的功能或信息。在这种环境中，服务管理器方法具有局限性。

因此，创建了组件上下文的概念。将来，此概念将会成为每个 UNO 应用程序的主要对象。它基本上是一个提供命名值的只读容器。其中一个命名值就是服务管理器。实例化时， 组件上下文 被传送到一个 组件。这可以理解为一种组件生存环境（关系类似于 shell 环境变量与可执行程序）。

ComponentContext 与 the ServiceManager

ComponentContext API

组件上下文仅支持 com.sun.star.uno.XComponentContext interface 接口。

  // module com::sun::star::uno
  interface XComponentContext : XInterface
  {
      any getValueByName( [in] string Name );
      com::sun::star::lang::XMultiComponentFactory getServiceManager();
  };

getValueByName() 方法返回一个命名值。getServiceManager() 是一种获取命名值 /singleton/com.sun.star.lang.theServiceManager 的便捷方法。它返回 ServiceManager singleton，因为多数组件需要访问服务管理器。组件上下文至少提供三种命名值：

Singletons (/singletons/...)

专业 UNO - API 概念 - 数据类型 - Singleton 中介绍了 singleton 概念。在 OpenOffice.org 1.0.2 中，只有 ServiceManagersingleton。从 OpenOffice.org 1.1 开始，增加了一个 singleton /singletons/com.sun.star.util.theMacroExpander，此 singleton 可用于在配置文件中扩展宏。在 IDL 引用中可以找到其他可能的 singleton 。

实现属性（尚未定义）

这些属性自定义某个具体实现，并且在每个组件的模块说明中指定。模块说明是某个模块（DLL 或 jar 文件）基于 XML 的说明，其中包含一个或多个组件的一般说明。

服务属性（尚未定义）

这些属性可以自定义与实现无关的某项具体服务，而且是在一项服务的 IDL 规范中指定的。请注意，服务环境属性不同于服务属性。服务环境属性无法更改，而且对于所有共享同一组件上下文的服务实例都是相同的。每个实例可以具有不同的服务属性，而且在运行时可以通过 XPropertySet 接口更改服务属性。

请注意，在上述模式中，ComponentContext 引用了服务管理器，而不是相反的情况。

除了前面讨论的接口以外，ServiceManager 还支持 com.sun.star.lang.XMultiComponentFactory 接口。

  interface XMultiComponentFactory : com::sun::star::uno::XInterface
  { 
           com::sun::star::uno::XInterface createInstanceWithContext(
               [in] string aServiceSpecifier,
               [in] com::sun::star::uno::XComponentContext Context )
               raises (com::sun::star::uno::Exception);
 
           com::sun::star::uno::XInterface createInstanceWithArgumentsAndContext(
               [in] string ServiceSpecifier, 
               [in] sequence<any> Arguments,
               [in] com::sun::star::uno::XComponentContext Context )
               raises (com::sun::star::uno::Exception);
 
           sequence< string > getAvailableServiceNames();
  };

它替代 XMultiServiceFactory 接口。对于两种对象建立方法，它提供了一个附加的 XComponentContext 参数。此参数使调用程序能够定义组件新实例可以接收的组件上下文。多数组件使用其初始组件上下文来实例化新组件。这样就可以进行环境传播（Context Propagation）。

环境传播.

上面的插图所示为环境传播。用户可能需要一个专用组件来获得自定义的环境。这样，用户只需包装一个现有的环境，即可建立一个新环境。用户覆盖所需的值，并将自己不感兴趣的属性授权给原始 C1 环境。用户定义实例 A 和 B 收到哪个环境。实例 A 和 B 将其环境传播到它们创建的每个新对象。这样，用户建立了两棵实例树，第一棵树完全使用环境 Ctx C1，而第二棵树则使用 Ctx C2。

可用性

可以在 StarSuite 6.0 和 OpenOffice 1.0 中使用组件上下文的最终 API。使用此 API 取代服务管理器部分中说明的 API。目前，组件上下文无法进行永久存储，因此，无法将命名值添加到一个已部署 OpenOffice.org 的环境中。在发布未来版本之前，新 API 目前没有其他优点。

兼容性问题和移植路径

纯服务管理器与组件上下文概念之间的折中

如前所述，办公软件内目前同时使用了这两个概念。ServiceManager 支持com.sun.star.lang.XMultiServiceFactory 和 idl>com.sun.star.lang.XMultiComponentFactory</idl> 接口。将 XMultiServiceFactory 接口调用授权给 XMultiComponentFactory 接口。服务管理器使用自己的 XComponentContext 引用来填充未设定的参数。可以用 'DefaultContext' 通过 XPropertySet 接口来获取 ServiceManager 的组件上下文。

  // Query for the XPropertySet interface.
  // Note xOfficeServiceManager is the object retrieved by the 
  // UNO URL resolver 
  XPropertySet xPropertySet = (XPropertySet)
           UnoRuntime.queryInterface(XPropertySet.class, xOfficeServiceManager);
 
  // Get the default context from the office server.
  Object oDefaultContext = xpropertysetMultiComponentFactory.getPropertyValue("DefaultContext");
 
  // Query for the interface XComponentContext.
  xComponentContext = (XComponentContext) UnoRuntime.queryInterface(
           XComponentContext.class, objectDefaultContext);

此解决方案允许使用同一服务管理器实例，不管此实例使用旧式 API 还是 新式 API。将来，所有 OpenOffice.org 代码将仅使用新 API。但是，还将保留旧 API，目的是为了确保兼容性。

前面介绍的折中有一个不足之处。服务管理器现在识别组件上下文，而在原来的设计中并非必要。这样，每个使用旧 API（简单的 createInstance()）的组件将中断环境传播（请参阅插图环境传播）。因此，建议在编写的每个新代码段中都使用新的 API。