多版本支持

   在商业产品开发中，如何有效的控制同一产品的多个衍生版本是一个非常重要的问题。客户的需求是多样化，差异化的。这些差异有些很小，可以通过参数配置，资源装载，skin切换等方式加以吸收，而有些则要求对界面布局和程序逻辑等作出较大调整。Witrix开发平台在系统基础架构方面为程序的客户化提供了有力的支持。
   1. 多版本控制的关键首先在于系统良好的模块划分。因此Witrix平台的beans,auth-map(权限归约规则)等配置文件格式都支持import/include等基础的分解策略,字符串资源和错误码映射等支持多重定义文件，而对于sql.xml(外部sql语句定义), meta.xml, biz.xml, hbm.xml等配置文件采用分模块动态装载机制。
   2. 在Witrix系统中定义了一个特殊的custom目录，规定了一般性的覆盖规则：custom目录作为系统根目录的影子目录，如果custom目录下存在同名文件，则优先装载custom目录下的文件。例如,如果custom目录下存在/_config/my/my.biz.xml文件，同时在根目录下也存在/_config/my/my.biz.xml文件, 则实际装载的是custom目录下的实现。这里的一个关键在于只有meta.xml(元数据)，biz.xml(BizFlow描述文件)，.lib.xml(tpl模板库)等具有一定完整性的文件才支持custom机制，而并不是所有资源都采用custom机制。如果每一个tpl文件，css文件，js文件等都优先从custom目录下装载，则很快就会出现循环引用，相对路径计算将会变得非常混乱，更重要的是我们将无法定义资源删除语义。
   3. 元数据文件，BizFlow描述文件，PageFlow描述文件等都支持复杂的extends机制，使得我们在扩展时只需要对于系统差异部分进行描述，而不是大段拷贝代码。
   4. tpl模板库和sql-map机制等采用的是追加覆盖策略。例如custom目录下的ui.xml标签库文件并不是直接覆盖系统根目录下的ui.xml文件，而是按照标签名进行细粒度的覆盖。系统编译时会自动检查覆盖标签的所有参数要求和原标签相兼容（例如允许增加参数而不允许减少参数），确保所有引用到原标签的tpl代码仍然有效。实际上整个witrix平台多版本扩展机制的一个设计目标就是确保平台主系统向各个分支产品的单向信息流动。在具体的表现上就是我们随时可以拷贝平台主系统覆盖到分支产品的相应目录，所有扩展实现与主系统实现保持分离状态。当然为了保持设计的弹性，系统中也定义了开关参数用来有选择的跳过一致性检查。