(C5)Tapestry IoC:Tapestry IoC Configurations

chinajavawolf

浏览: 116779 次
性别:
来自: 哈尔滨

最近访客更多访客>>

w363042254

hao_chun

feifeng3000

yao_zonghai

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

Tapestry

Tapestry IOC 浏览器 Office Eclipse

本文翻译出处 http://tapestry.apache.org/tapestry5/tapestry-ioc/configuration.html

本人翻译目的是用来学习Tapestry5的,共享出来希望大家批评指正。计划持续翻译。

chinajavawolf

Tapestry IoC 配置

Tapestry IoC的一个关键概念是分布配置。这个概念借鉴Eclipse Plugin API和Tapestry5 IoC之前的HiveMind。

如此漂亮的术语，意味着什么呢？

分布配置是Tapestry IoC支持扩展的一个关键特性。

这个分布的部分事实上是引用任何可以贡献给任何服务的配置（服从通常的可见规则适用于私有服务）。

这似乎深奥，但非常容易上手，通过例子解释一下：

假定你正构建一个服务，比方说，map映像一个扩展了FileServicer接口的文件。有很多不同的但都实现了FileServicer接口的服务，跨越多个不同的模块，每个为一个特别类型的文件做特定的事。(通过扩充的文件确定)

一个核心服务使用这个配置来选择一个特定的FileService接口：

public static FileServicer buildFileServicerDispatcher(Map<String,FileServicer> contributions)
{
return new FileServiceDispatcherImpl(contributions);
}

为了提供一个值给contribution参数，Tapestry将从服务的贡献方法中收集贡献。它将确保key和value匹配显示的泛型类型（String 为key类型，FileServicer为value类型）。这个map将被装配然后传递给服务构建器方法，并且从那里，进入FileServiceDispatcherImpl构造器。

值来自哪里？服务贡献器方法，方法以"contribute":开头。

public static void contributeFileServicerDispatcher(MappedConfiguration<String,FileServicer> configuration)
{
configuration.add("txt", new TextFileServicer());
configuration.add("pdf", new PDFFileServicer());
}

像服务构建器和服务装饰器方法，我们可以注入我们想要得服务。

public static void contributFileServicerDispatcher(MappedConfiguration<String,FileServicer> configuration,
@InjectService("TextFileServicer") FileServicer textFileServicer,
@InjectService("PDFFileServicer") FileServicer pdfFileServicer,
{
configuration.add("txt", textFileServicer);
configuration.add("pdf", pdfFileServicer);
}

扩充性来自多个模块可能都导致相同的服务配置:

public static void contributeFileServicerDispatcher(MappedConfiguration<String,FileServicer> configuration)
{
configuration.add("doc", new WordFileServicer());
configuration.add("ppt", new PowerPointFileServicer());
}

现在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对象被执行的顺序。

public static Runnable buildStartup(final Collection<Runnable> configuration)
{
return new Runnable()
{
public void run()
{
for (Runnable contribution : configuration)
contribution.run();
}
};
}

这里，我们甚至不需要为这个实现而分割类，为这个实现我们使用一个内部类。重点是，配置被提供给构建器方法，传递它给服务实现。

在贡献方面，一个服务贡献方法看作是一个Configuration对象。

public static void contributeStartup(Configuration<Runnable> configuration)
{
configuration.add(new JMSStartup());
configuration.add(new FileSystemStartup());
}

这个Configuration接口只是定义了一个专一方法：add()。这是非常有意图的：你唯一可以做的就是添加新的项目。如果我们传递在一个Collection内，你可能被吸引去检查它的值，或者删除它们。。。但是运行在面前的事实是执行这些服务贡献方法的顺序是未知的。

对于可读性（如果Java仍继续支持这个概念），我们已经参数化了这个方法的配置参数，强制它为一个java.lang.Runnable实例，以致其匹配相应的参数。这是一个选择，但通常这非常有用。在任何时候，试图贡献一个没有扩展或实现Runnable类型的对象都将导致一个运行时警告（并且这个值将被忽略）。

Tapestry 只支持简单形式的参数化类型。Java泛型支持一个宽形式，“通配符”，是Tapestry不接受的。

有序列表

有序列表更通用。使用一个有序的列表，这个贡献在被提供给服务构建器方法前被存储在一个正确的顺序内

此外，服务贡献方法被调用的顺序是未知的。因此，被加入给配置的对象的顺序是未知的。代替的是，我们强制项目的顺序毕竟所有贡献已经被添加。因为使用服务装饰器，我们通过每个贡献对象的唯一id设置顺序，然后通过id确定那个项目在列表前面，那个必须跟谁其后。

这样看来，如果我们的Startup服务需要一个明确的顺序用来启动：

public static Runnable buildStartup(final List<Runnable> configuration)
{
return new Runnable()
{
public void run()
{
for (Runnable contribution : configuration)
contribution.run();
}
};
}

注意这个服务构建器方法隔离了如何排序项目顺序的细节。它不用必须知道ids和之前还有之后的必需品。通过使用一个List类型参数，我们已经触发了Tapestry去收集所有排序信息。

对于我们的服务贡献方法，我们必须提供一个OrderedConfiguration类型参数：

public static void contributeStartup(OrderedConfiguration<Runnable> configuration)
{
configuration.add("JMS", new JMSStartup());
configuration.add("FileSystem", new FileSystemStartup(), "after:CacheSetup");
}

通常你不用关心排序，add方法的第一种形式因而被使用。排序规则将发现一个基于其他贡献对象约束的对象位置（这里是JMSStartup 实例）。

对于"FileSystem"贡献，一个约束已经被指定，指示FileSystem应该排在某些其他的名为"CacheSetup"的贡献之后。一些这样的排序约束可以被指定（add()方法接受可变数目的参数）。

传递的对象可以为null：这是有效的，并且视为一个"连接点":在列表内的相关的点对于他们自身没有任何意义，但当排序其他项目时可被使用。

Null值，一旦排序就被删除（List传递给服务构建器方法不包括任何null值）。此外，他们被允许作为站位符，为实际贡献的对象在他们自身周围组织。

映像的配置

象较早的例子中讨论的，映像的配置也被支持。传递的key必须唯一。当冲突发生时，Tapestry将记录警告（确定来源，根据调用的方法，冲突的），然后忽略冲突的值。

这个值不应为null。

对于key类型是字串的映像的配置， CaseInsensitiveMap 将会自动地被用 (并且传给服务构建器方法), 帮助确定忽略大小写是自动和普遍的。

注入的资源

除了注入服务在贡献器方法内（经由@InjectService 和 @Inject标注），Tapestry 将切断参数类型允许其他内容被注入。

² ObjectLocator: 有权使用其他可见的服务给贡献模块。

这些情况不需要标注。

分享到：

(C6)Tapestry IoC:Type Coercion | (C4)Tapestry IoC:Tapestry IoC Decorators

2007-05-26 09:19
浏览 1745
评论(0)
论坛回复 / 浏览 (0 / 2300)
查看更多

发表评论

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

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论