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的解析器并不能識別其中的細節，它也不需要識別其中的細節。