群组首页 → 企业架构 → Tapestry → 知识库 → (C5)Tapestry IoC:Tapestry IoC Configurations
原创作者: chinajavawolf   阅读:1025次   评论:0条   更新时间:2011-05-26    
本人翻译目的是用来学习Tapestry5的,共享出来希望大家批评指正。计划持续翻译。
chinajavawolf  
Tapestry IoC 配置
 
Tapestry IoC的一个关键概念是分布配置。这个概念借鉴Eclipse Plugin API和Tapestry5 IoC之前的HiveMind。
 
如此漂亮的术语，意味着什么呢？
 
分布配置是Tapestry IoC支持扩展的一个关键特性。
 
这个分布的部分事实上是引用任何可以贡献给任何服务的配置（服从通常的可见规则适用于私有服务）。
 
这似乎深奥，但非常容易上手，通过例子解释一下：
 
假定你正构建一个服务，比方说，map映像一个扩展了FileServicer接口的文件。有很多不同的但都实现了FileServicer接口的服务，跨越多个不同的模块，每个为一个特别类型的文件做特定的事。(通过扩充的文件确定)
 
 
一个核心服务使用这个配置来选择一个特定的FileService接口：
 
  1. public static FileServicer buildFileServicerDispatcher(Map<String,FileServicer> contributions)   
  2. {   
  3.    return new FileServiceDispatcherImpl(contributions);   
  4. }   
 
为了提供一个值给contribution参数，Tapestry将从服务的贡献方法中收集贡献。它将确保key和value匹配显示的泛型类型（String 为key类型，FileServicer为value类型）。这个map将被装配然后传递给服务构建器方法，并且从那里，进入FileServiceDispatcherImpl构造器。
 
值来自哪里？服务贡献器方法，方法以"contribute":开头。
  1. public static void contributeFileServicerDispatcher(MappedConfiguration<String,FileServicer> configuration)   
  2. {   
  3.    configuration.add("txt", new TextFileServicer());   
  4.    configuration.add("pdf", new PDFFileServicer());   
  5. }    
  6.   
像服务构建器和服务装饰器方法，我们可以注入我们想要得服务。
  1. public static void contributFileServicerDispatcher(MappedConfiguration<String,FileServicer> configuration,   
  2.   
  3.    @InjectService("TextFileServicer") FileServicer textFileServicer,   
  4.       
  5.    @InjectService("PDFFileServicer") FileServicer pdfFileServicer,   
  6. {   
  7.    configuration.add("txt", textFileServicer);   
  8.    configuration.add("pdf", pdfFileServicer);   
  9. }   
扩充性来自多个模块可能都导致相同的服务配置:
  1.   public static void contributeFileServicerDispatcher(MappedConfiguration<String,FileServicer> configuration)   
  2. {   
  3.    configuration.add("doc", new WordFileServicer());   
  4.    configuration.add("ppt", new PowerPointFileServicer());   
  5. }   
.
现在FileServicerDispatcher构建器方法获得了一个Map通过它内部的至少四个途径。
 
因为Tapestry IoC是高度动态的（它浏览可见的JAR manifest文件来确定模块构建器类），这个FileServicerDispatcher服务可以在一个模块内，并且其他的贡献的模块（例如一个贡献Office文件服务）可以在更晚的时间被写。没有变化对于FileServicerDispatcher服务或它的模块构建器类，新的服务"plug into"全面的解决方案，只是通过拥有他们的JAR在运行时classpath上。
 
配置类型
 
有三个不同的配置样式（用来匹配贡献）。
1.          无序集合Collection。贡献被简单的添加并且顺序不重要。
2.          .有序列表list。贡献作为一个有序列表被提供。贡献必须通过给每个贡献对象的唯一id确认顺序，通过在值之间的向前和向后依赖。
3.          Map映像。贡献提供唯一的key和相对的value。
 
  •   无序集合（Collection）
 
一个服务构建器方法可以通过定义一个java.util.Collection类型参数收集一个无序的值列表。此外，你应该标识聚集的参数类型。Tapestry 将定义参数化的类型并且确保所有贡献匹配。
 
有一点要记住的是,贡献发生的顺序是未指定的。可能有大量模块，每个模块有零个或更多个方法贡献给服务。这些方法被调用的顺序是未知的。
 
例如，这是一种需要一些Runnable对象的Startup服务。它不关心Runnable对象被执行的顺序。
 
  1. public static Runnable buildStartup(final Collection<Runnable> configuration)   
  2. {   
  3.    return new Runnable()   
  4.    {   
  5.      public void run()   
  6.      {   
  7.        for (Runnable contribution : configuration)   
  8.          contribution.run();   
  9.      }   
  10.    };   
  11. }   
 
这里，我们甚至不需要为这个实现而分割类，为这个实现我们使用一个内部类。重点是，配置被提供给构建器方法，传递它给服务实现。
 
在贡献方面，一个服务贡献方法看作是一个Configuration对象。
  1. public static void contributeStartup(Configuration<Runnable> configuration)   
  2. {   
  3.    configuration.add(new JMSStartup());   
  4.    configuration.add(new FileSystemStartup());   
  5. }       
这个Configuration接口只是定义了一个专一方法：add()。这是非常有意图的：你唯一可以做的就是添加新的项目。如果我们传递在一个Collection内，你可能被吸引去检查它的值，或者删除它们。。。但是运行在面前的事实是执行这些服务贡献方法的顺序是未知的。
 
对于可读性（如果Java仍继续支持这个概念），我们已经参数化了这个方法的配置参数，强制它为一个java.lang.Runnable实例，以致其匹配相应的参数。这是一个选择，但通常这非常有用。在任何时候，试图贡献一个没有扩展或实现Runnable类型的对象都将导致一个运行时警告（并且这个值将被忽略）。
 
Tapestry 只支持简单形式的参数化类型。Java泛型支持一个宽形式，“通配符”，是Tapestry不接受的。
  • 有序列表
 
有序列表更通用。使用一个有序的列表，这个贡献在被提供给服务构建器方法前被存储在一个正确的顺序内
 
此外，服务贡献方法被调用的顺序是未知的。因此，被加入给配置的对象的顺序是未知的。代替的是，我们强制项目的顺序毕竟所有贡献已经被添加。因为使用服务装饰器，我们通过每个贡献对象的唯一id设置顺序，然后通过id确定那个项目在列表前面，那个必须跟谁其后。
 
这样看来，如果我们的Startup服务需要一个明确的顺序用来启动：
  1. public static Runnable buildStartup(final List<Runnable> configuration)   
  2. {   
  3.    return new Runnable()   
  4.    {   
  5.      public void run()   
  6.      {   
  7.        for (Runnable contribution : configuration)   
  8.          contribution.run();   
  9.      }   
  10.    };   
  11. }   
 
注意这个服务构建器方法隔离了如何排序项目顺序的细节。它不用必须知道ids和之前还有之后的必需品。通过使用一个List类型参数，我们已经触发了Tapestry去收集所有排序信息。
 
对于我们的服务贡献方法，我们必须提供一个OrderedConfiguration类型参数：
  1.   
  2. public static void contributeStartup(OrderedConfiguration<Runnable> configuration)   
  3. {   
  4.    configuration.add("JMS", new JMSStartup());   
  5.    configuration.add("FileSystem", new FileSystemStartup(), "after:CacheSetup");   
  6. }     
 
通常你不用关心排序，add方法的第一种形式因而被使用。排序规则将发现一个基于其他贡献对象约束的对象位置（这里是JMSStartup 实例）。
 
对于"FileSystem"贡献，一个约束已经被指定，指示FileSystem应该排在某些其他的名为"CacheSetup"的贡献之后。一些这样的排序约束可以被指定（add()方法接受可变数目的参数）。
 
传递的对象可以为null：这是有效的，并且视为一个"连接点":在列表内的相关的点对于他们自身没有任何意义，但当排序其他项目时可被使用。
 
Null值，一旦排序就被删除（List传递给服务构建器方法不包括任何null值）。此外，他们被允许作为站位符，为实际贡献的对象在他们自身周围组织。
 
映像的配置
 
象较早的例子中讨论的，映像的配置也被支持。传递的key必须唯一。当冲突发生时，Tapestry将记录警告（确定来源，根据调用的方法，冲突的），然后忽略冲突的值。
 
这个值不应为null。
 
对于key类型是字串的映像的配置， CaseInsensitiveMap 将会自动地被用 (并且传给服务构建器方法), 帮助确定忽略大小写是自动和普遍的。
 
注入的资源
 
除了注入服务在贡献器方法内（经由@InjectService 和 @Inject标注），Tapestry 将切断参数类型允许其他内容被注入。
²        ObjectLocator: 有权使用其他可见的服务给贡献模块。
这些情况不需要标注。
评论 共 0 条 请登录后发表评论

发表评论

您还没有登录,请您登录后再发表评论

文章信息

知识库: Tapestry
Global site tag (gtag.js) - Google Analytics