Translator in HiveMind

    很多情况下需要将一个用字符串代表的属性转化成特定的对象，比如说Boolean,Integer或Date。HiveMind通过Translator完成这项工作，可以在<attribute>或<element>里面声名一个Translator。
    HiveMind对Translator的支持由一个叫做TranslatorManager的类负责管理。考虑到对Translator的扩展性，它对Translator的组织比较特别。首先，它需要所有的Translator都继承同一个接口，并且对构造函数也作了限定。其次，它通过扩展点配置来扩展自身。
    在HiveMind的framework包中有一个名为Translators的配置扩展点，在它的schema中定义了配置translator的格式。有趣的是在这个schema中递归的使用了Translator属性，使整个格式让人看上去很费解。解决这个循环调用的方法是在内核预设Translator的目的就是支持在生成扩展点的时候不会造成请求循环。当有请求向TranslatorManager申请Translator时，TranslatorManager并不会马上去读取配置扩展点的数据，只有当找不到需要的Translator时才会去读取Translator的配置数据。因为预设了class，service，smart，instance这四个Translator所以在读取配置数据时不会产生对Translator的循环依赖。
    在预定的Translator有一种叫做object的Translator,它需要ObjectProvider配合使用。ObjectProvider的作用和Translator非常相似，完成的工作也很相像。不同的是ObjectProvider必须继承另外的接口。这样做的目的，一方面可能是为了增加灵活性，让Object可以有多种途径取值，而不用为每种取值方式从新编写一个Translator，也不用知道当前有那些ObjectProvider可用。另一方面，这样写也可以让取值的语意更加明确，因为Translator属性中必须使用一个前缀来申明用那一种ObjectProvider来获取对象。比如说当应用中集成了spring之后，如果想获取spring中的某一个bean,那么使用如下的格式即可<...  value = "spring:beanName"/>。
    Translator是HiveMind内核支持的一项工作，并且可以通过配置来扩展自己。在其它HiveMind内核支持的工作都可以看到这种现象，内核代码和关键的配置是不能完全脱离的。至少为了更高一点的效率是不能完全脱离的。