看FME的例子，对tfs文件格式，生成一个dll，丢到FME的安装目录或plugins目录，就能够支持其访问。太神奇，没有任何配置。现在的插件系统，虽说有人推崇配置，有的反对配置，但是真正做到加入dll就自动识别的，好像没有。如果没有配置，也至少存在一种简单约定的。最简单的约定有：插件放到某个目录；插件按照某种格式编写；插件的文件名按照某种规则。但是FME的例子让人疑惑了。它神通广大吗？
过程摸索中采用过几种暴力猜测法：注册表搜索“FME”；目录文件搜索关键词；在FME目录中打开各种文件一个个看文本内容，导出dll格式。依稀怀疑与formats.db文件有关。
然后清醒脑袋，先想好大方向。从Workbench中的原始数据功能开始入手，发现里面支持tfs文件格式。首先怀疑tfs的读写功能是新生成的例子dll支撑的，还是原来就自带的。搭建一个流程，就是对dfs类型数据进行简单的查看，发现可以正常进行。然后删掉那个dll再试，发现日志提示找不到对应的模块。可见，这个dll真是tfs文件读写插件。
难道只要存在dll就可以进行读写吗？找回那个dll，改个名，再运行，发现依然提示找不到模块。这样看来，tfs类型认的是指定的dll名。
那么这个规则又是如何配置指定的呢？看到FME支持的类型对话框中出现的tfs项目栏，提取“TFS_FIXEDSCHEMA”关键字眼，在注册表中搜索和FME的安装目录下进行包含文字内容查找，终于发现踪迹：文件formatsinfo\tfs_fixedschema.db。里面内容是“TFS_FIXEDSCHEMA|Text Feature Store Fixed Schema Format(TFS)|FILE|BOTH|BOTH|NO|TFS Files(*.tfs)%*.tfs%All Files%*.*||NO|NO|NO”。所有的规则配置都是这些db文件进行指定的。
一切疑惑得解：一类格式对应多个读写插件；每个插件都是唯一的，通过最前面的那个关键词指定。这个关键词同样也就是dll的名称。FME的文件类型框中的内容来源于：安装目录下的formats.db文件，其中每一行对应一个插件；然后再遍历子formatsinfo目录下的所有db文件，进行扩充。以后如果添加一种类型的数据，要提供两件事：简单的把dll Copy到根目录或者plugins目录；另外再加上一行信息到根目录下的formats.db文件或者子目录中的已有或新建的db文件中。FME给人的一点疑惑就是：安装程序中已包含了db文件；这样就使得简单的Copy一个dll就可以了。
一个读写插件中能否对多种数据类型进行操作呢？FME的工厂和函数又是通过什么规则自定义扩充的呢？还有FME的很多约定需要了解。
仔细的看FME的读写插件开发例子，依稀提有formats.db的信息。看来还是要精读啊。
评论