canonical

    目前的框架设计中，引入元数据(metadata)已经是必然的事情，jdk5.0的annotation机制也为metadata的物理驻留位置提供了新的选择。常见的一些元数据设计方案中往往是元数据直接驱动系统的展现甚至运行过程（例如普元EOS)，大有完全取代程序代码的趋势，这无疑是对元数据概念的一种滥用。一般在界面层所使用的元数据其实类似于某种新的界面描述语言，即某种特定目的的DSL(domain specific language). 但这种描述一般是不完备的， 一旦遇到扩展情况， 往往需要很多额外的工作。
    实际上并不是所有信息都要在独立的xml 中描述, 前台模板页面本身就可以是一种元数据, 前台元素之间的关联已经隐含表达了多种关系, 不需要把这些关联再在额外的xml文件中重复.  比如说一个数据集展现在页面上的时候需要支持几种操作，即对应的需要显示几个按钮. 在witrix平台的tpl模板中, 我们的调用方式大概如下
        <ui:EditTable pager="${pager}" dsMeta="${dsMeta}">
        <buttons>
          <ui:RemoveRowButton/>
          <ui:EditRowButton/>
        </buttons>
        </ui:EdiTable>
    操作集合这一信息仅在模板中表达一次.  实际上很多时候, 不同的界面我们需要展示不同的操作集合, 它本身并不一定是数据集内在的性质. 数据集的属性只能是支持全部操作的集合, 它并不需要直接对应到界面上. 对于多个界面我们需要尽量共用一个meta配置.

    在witrix平台的元数据方案中，关键是采用pull mode, 由前台模板系统驱动， 模板决定使用何种资源（包括元数据），而不是由元数据驱动整个系统的展现。当一个元数据条目不适用的时候我们可以忽略它，但是仍然可以使用元数据配置中的其他部分。这与我们的jsplet web框架的设计是一脉相承的。

    元数据的驻留形式本身也是很有意思的问题。假设现在我们需要描述如下信息：本字段采用input框显示，它有一个参数value. 它的meta形式可以如下，
       <inputor type="TextInput">
          <arg name="value" />
       </inputor>
    我们也可以选择如下形式
       <inputor>
        <input type="text" value="${value}" />
       </inputor>
    第二种方式的特殊之处是它选择了与html规范本身兼容的表达形式，即寄生于html格式之中。这种设计的好处在于我们只需要一个通用的模板引擎，而不需要任何特定于该控件的解析器，就可以产生最终所需的文本输出。这种元数据表达方式更重要的地方在于它是导向更高复杂性层次的自然途径。例如我们现在需要一种更加复杂的自定义控件来显示该字段，则
       <inputor>
        <ui:DateInputor value="${value}" />
       </inputor>

    在元数据的设计中，适可而止永远都是我们需要铭记在心的核心原则。对元数据描述的范围要适可而止，不要试图包罗万象。例如，在界面元数据的设计中不要对于数据供体有任何假定。一个前台表格，无论它的数据是数据库中的一组记录, 还是通过pop3协议收取的一组信件，应该都不影响它对于meta的使用。元数据引擎所能够直接理解的粒度也要适可而止。在witirx平台的元数据方案中，viewer和inputor等配置段其实是由tpl模板引擎负责解析的，在DataSourceMeta的解析器并不能识别其中的细节，它也不需要识别其中的细节。