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