分类：
2011-03-04 13:05:50
原文地址：EMF--深入研究到骨子里--15 作者：mtloveft
generated_package
dynamic_package
factory_override
extension_parser
protocol_parser
content_parser
content_handler
uri_mapping
package_registry_implementation
下面一一详细介绍
generated_package是最重要的扩展点了。
就是注册一个EPackage,注册时必须提供一个唯一的URI,
同时还必须指出,EPackage类,genModel属性是可选的,即genmodel文件的地址。
它将被注册到一个全局的EPackage.Registry.INSTANCE里。
ecore项目注册了3个EPackage
定义分别如下
uri=""
class="org.eclipse.emf.ecore.EcorePackage"
genModel="model/Ecore.genmodel"/>
uri=""
class="org.eclipse.emf.ecore.xml.type.XMLTypePackage"
genModel="model/XMLType.genmodel"/>
uri=""
class="org.eclipse.emf.ecore.xml.namespace.XMLNamespacePackage"
genModel="model/XMLNamespace.genmodel"/>
这3个EPackage就是所有EMF项目的基础了。
每个应用程序注册自己的EPackage时都要用到以上ECorePackage。
而从XMLSchema导入的EMF程序则要用到XMLTypePackage。
dynamic_package扩展点是注册动态EPackage。
所谓动态EPackage,就是一个EPackage可能被分割注册到多个项目中,
但是他们的URI都是相同的。这个扩展点很有用的,扩展性也很强,是柔软设计。
比如我设计好了一个xml Schema,但不能确定这个xml Schema将来会扩展到什么程度,
但知道一定会扩展的。这时利用这个dynamic_package,就可以解决问题。
在我的实际项目中就有这个问题。比如在一个xmlSchema里,我定义了,ftp,snmp,telnet,
shell等功能,但将来肯定会扩展,比如什么windows的command,tl1,还有自定义的通信等。
这样xmlSchema是不断扩展的。利用dynamic_package就能解决这个问题。
否则,xmlSchema文件本身将不断的更新。xmlSchema文件也将被分割成多个Schema了。
柔软,扩张,都将大大提高。
factory_override对EFactory进行重写,要提供URI。我认为这个很少用到。
extension_parser这个就经常用到了。就是根据文件的后缀子进行文件类型。
注册了的扩展点将被保存到全局变量Resource.Factory.Registry.INSTANCE里。
需要提供type和class。
protocol_parser扩展点是注册一个特殊URI的protocol。首先要知道URI的构成比如
schema:schema-specificPart#optionFragment
经常提到的是URL。根据RFC3305还有一个URN。
URI(Uniform Resource Indentifier),统一资源标识符
URL(uniform Resource Location) ,统一资源定位符
URN(uniform Resource Name) ,统一资源名称
其实这3个东西很好理解的。URN就是名字,URL就是地址。
而URI即使以上两个的结合。
URL的构成是protocol://host/dir
上面的dir也可以是文件,所以以上格式中的dir就是URN,
protocol://host就是URL。是资源存放的位置。
URL中的protocol就是URI中schema啦。
这个扩展点就是解析URI时,遇到不能解析的protocol时将被调用。
注册了的扩展点也将被保存到全局变量Resource.Factory.Registry.INSTANCE里。
content_parser扩展点是注册对文件内容进行解析来判断文件类型的扩展点。
简单的说,比如给定一个XML文件,对这个XML文件的root元素进行解析,
如果是xxx,那么就可以确定这个XML文件是我们定义好的,这个解析需要先注册。
注册了的扩展点将被保存到全局的Resource.Factory.Registry.INSTANCE变量里。
这个扩展点需要指出contentTypeIdentifier,这个contentTypeIdentifier又是
org.eclipse.core.contenttype.contentTypes这个扩展点定义的。所以先要
扩展org.eclipse.core.contenttype.contentTypes,之后才能扩展content_parser。
content_handler扩展点是注册一个根据handler判断文件类型的扩展点。
注册了的扩展点将被保存到ContentHandler.Registry.INSTANCE里。
uri_mapping扩展点是用来进行URI转换时调用的。
package_registry_implementation没用过,感觉没什么用,就不说了。
读这些扩展点的程序分别为
GeneratedPackageRegistryReader
DynamicPackageRegistryReader
FactoryOverrideRegistryReader
ExtensionParserRegistryReader
ProtocolParserRegistryReader
ContentParserRegistryReader
ContentHandlerRegistryReader
URIMappingRegistryReader
package_registry_implementation扩展点是由一个内部类读入的。
读入+解析的过程就不介绍了。很简单的。
有一点需要说明的是,这些读入过程都是在EMF插件启动时进行的。
当一个EMF应用程序插件启动时,可能EMF插件还没启动,
因为所有的EMF应用程序插件都依赖于EMF插件,所以EMF插件肯定
先被启动,也就是说,这些扩展点先被预读了。
