GacUI：XML Resource

https://github.com/vczh/GacUIBlog

GacUI XML Resource大約在2013年左右開始成形，但是最終的功能是在2018年左右才固定下來的，在這個階段里，GacUI XML Resource一共經歷了五個版本，而且每個版本之間的差異還很大，這里的差異主要指的是如何處理XML，而寫法上卻沒什么變，

1. 當XML視窗真的是一個資源

早期GacUI是一個純粹的C++庫，所有介面設計的決定都是圍繞著如何讓C++操作起來更簡便而做出的，而GacUI XML Resource最初僅僅是為了免去加載資源的煩惱，畢竟一個應用程式光是圖示就有一大堆，一個一個加載進來實在是太麻煩了，所以GacUI XML Resource允許你寫一個XML檔案當目錄，在啟動應用程式的時候，所有的資源都會跟隨著XML一起進來，這個時候不管是XML還是檔案們都是分離的，

但是隨著demo的復雜度與日俱增，我發現C++在表達UI的這方面還是有硬傷，總的來說就是代碼里面的噪音太多了，在考察了世界上各種XML或者JSON的UI語言之后，我毅然選擇了XML，在當時JSON作為一個潮流聲勢浩大，我還跟很多人都討論過語言的細節問題，最后還是覺得XML對GacUI最合適，但是開發視窗的資源就面臨著一個無法避免的問題：反射，今天Gaclib的C++物件反射我認為已經比較成熟了，甚至這個反射庫允許你在Workflow腳本里面創建新的型別并對C++的型別做多重繼承，反射庫還提供了C++代碼生成的hint，整個腳本可以完全翻譯成C++，那么在運行的時候就不需要反射的支持了，GacBuild.ps1正是依賴了這一個功能做出來的，

有了反射，我就可以在運行時用字串當C++類名來創建控制元件，可以訪問每一個控制元件的屬性，可以序列化和反序列化所有struct、enum和其他值型別等等，最后只需要在加載UI資源的時候做一些調整就好了，這些調整主要來源于C++和XML的用法不同，為了C++優化的介面總會在一些細節上讓XML用起來不太舒服，在前面的博客中已經提到了，布局自己是一棵樹，而把控制元件放進布局的時候實際上是把控制元件控制的那個布局圖元子樹的根節點放進去，這個區別在XML就抹平了，但是C++操作起來是不一樣的，有些屬性在C++里面表現為陣列，有些表現為串列，這主要是出于performance上的考慮，就像<Table>是不鼓勵你頻繁更改表格結構的，所以它會需要你先告訴表格有多少行列，然后再給行列設定屬性，而XML寫在那里是不會變的，做這種要求就是無稽之談了，編譯器數一下Rows和Columns下面各有多少XML tag就好了，

<Window Text="GacUI">
  <Table AlignmentToParent="left:0 top:0 right:0 bottom:0" BorderVisible="true" CellPadding="5" MinSizeLimitation="LimitToElementAndChildren">
    <att.Rows>
      <CellOption>composeType:Percentage percentage:1.0</CellOption>
      <CellOption>composeType:MinSize</CellOption>
    </att.Rows>
    <att.Columns>
      <CellOption>composeType:Percentage percentage:1.0</CellOption>
      <CellOption>composeType:MinSize</CellOption>
      <CellOption>composeType:MinSize</CellOption>
    </att.Columns>

    <Cell Site="row:0 column:0 columnSpan:3">
      <Label Text="Welcomg to GacUI!"/>
    </Cell>

    <Cell Site="row:1 column:1">
      <Button ref.Name="buttonOK" Text="OK"/>
    </Cell>

    <Cell Site="row:1 column:2">
      <Button ref.Name="buttonCancel" Text="Cancel"/>
    </Cell>
  </Table>
</Window>

這就是當時XML的樣子，跟今天的XML幾乎是沒什么區別的，只是很多功能都不存在，這個視窗畫了一個兩行三列的表格，第一行整行放了個<Label>，右下角放了個<Button>，視窗變大的時候，按鈕永遠粘著右下角，視窗變小的時候，如果按鈕擠到了那行字的空間，那么GacUI就會阻止你繼續把視窗變小，而且表格的每一個元素之間的間隔，還有距離視窗邊緣的間隔都保留在5個像素，在支持高DPI視窗之后，對5個像素的解讀就是100%縮放下的5像素，改到了200%那就變成10個像素了，字體大小和幾何圖形的邊緣也類似，所以GacUI的程式不管DPI改成什么樣子，幾乎都是沒什么變化的，與GDI渲染器不同的是，Direct2D渲染器的效果并不模糊，因為Direct2D支持浮點尺寸，GDI不行，

這個設計跟localization還有關系，考慮到不同語言的OK和Cancel可能長度還不一樣，這種使用<Table>的方法會讓Cancel的文字變長之后自動把OK擠開，

那如何回應按鈕事件呢？在當時只能通過給按鈕標記ref.Name，運行之后用這個名字從加載后的視窗中查詢到這個物件，強制轉換成vl::presentation::controls::GuiButton，最后再把事件掛上去，

在折騰了好幾個月之后，GacUI就第一次實作了從XML加載視窗，但是這種寫法的缺點太多了，不僅反射帶來exe體積的膨脹，而且UI的屬性也只能是初始化的時候寫死的，距離MVVM的目標那還是差遠了，

2. 在XML中添加Workflow腳本的支持，實作資料系結和事件處理

加上資料系結，性質就完全不同了，這也是Workflow腳本語言的來源，雖然Workflow必須寫完一個模塊才可以編譯，但是如果在XML里面支持運算式，那只要把沒一個運算式都改寫成一個函式，多少個運算式就出來多少個模塊，那也是可以運行起來了，雖然資料系結實作起來有點繞，但是總的來說只要注冊反射的時候，把屬性和事件捆綁在一起就好了，VlppReflection提供了這一功能，

資料系結在XML的語法也很直接，一個屬性的賦值可以是Attribute="Value"，但是只要加上不同的binder，就可以對值產生不同的解讀，譬如說可以在選單的串列項里面參考同一個XML或者別的XML帶的圖片檔案：Image-uri="res://Path/To/The/Image.png"，最簡單的資料系結就是一個Workflow計算出來的一次性答案：Text-eval="let today = Sys::GetLocalTime() in ($'$(today.year)年$(today.month)月$(today.day)日')"，當然了，GacUI提供了localization的API可以用，顯示年月日不需要真的這么麻煩，如果使用-bind，那么GacUI就會知道，你是想實時跟蹤這個運算式，

你可以做一個程式，兩個文本框輸入數字，第三個文本框顯示結果，而你只需要這樣寫：

<SinglelineTextBox Readonly="true" ref.Name="textBox3" Text-bind="(cast int textBox1.Text) + (cast int textBox2.Text) ?? '請輸入整數'">

那么只要兩個標記為ref.Name="textBox1"和ref.Name="textBox2"的文本框內容一改，那這個文本框的內容就會跟著改為他們倆的和，如果輸入的內容不是數字，那么cast運算式會拋例外，然后被??運算子接住，顯示請輸入數字，非常智能，不過真的要嚴格使用MVVM的話，其實抽象的更多一點，把ViewModel的兩個屬性系結到文本框上，然后第三個文本框從ViewModel的屬性系結回來，請輸入整數這個數字還要放在<LocalizedStrings>里面支持多國語言的翻譯，等等，

在處理這個運算式的時候，因為文本框的GetText函式、SetText函式和TextChanged事件被捆綁到了一起，那么GacUI自然就知道實時跟蹤這個運算式需要給兩個TextChanged都掛上回呼函式，在文本框的內容被用戶輸入的同時，事件會被觸發，然后不管呼叫的是拿一個回呼函式，這行代碼都會重新運行一遍然后呼叫textBox3->SetText，具體實作的時候由于運算式可以很復雜，所以細節上要比這里說的麻煩很多，具體可以參考考不上三本也會實作資料系結（一）、（二）、（三），

而在XML添加回呼函式的道理也是差不多的，譬如說上一段的例子里，buttonOK點一下就把自己關掉，就可以寫成：

<Window ref.Name="self" ...>
  ...
  <Button ref.Name="buttonOK" Text="OK" ev.Clicked-eval="self.Close();"/>
  ...
</Window>

事件處理被我規定為只能寫一個陳述句，所以多個陳述句就需要使用大括號，而覺得一行寫不下去也可以，<ev.Clicked-eval>可以單獨變成一個tag，然后把代碼用<![CDATA[ ... ]]>包起來就可以了，

實作到這里，GacUI的加載變得非常慢，除了要根據XML的內容使用反射初始化視窗以外，還需要把XML的每一個運算式和事件回呼都編譯成單獨的Workflow module，然后運行起來，exe體積大也是一個缺點，啟動速度慢也是一個缺點，兩個缺點加在一起，就可以讓很多人打消使用GacUI的念頭了，這當然是不行的，

3. 把整個XML編譯成一個Workflow Assembly

問題要一個一個解決，exe體積大只能不要反射，到了這一步還不可行，而啟動速度慢的問題，則可以使用編譯與啟動分開來解決，而要這么做，那么在運行時一邊讀XML一邊反射的方法就不可行了，那么怎么辦呢？

當時做出了一個決定，就是把整個GacUI XML Resource凡是非檔案資源的部分都合并成一個單獨的Workflow module，通俗一點也就是說，你寫一個

<Window ref.Class="path::to::my::MainWindow">
</Window>

那我也就不把XML拆開了，直接翻譯成

module path_to_my_MainWindow;
using presentation::control::*;

namespace path
{
    namespace to
    {
        namespace my
        {
            class MainWindow : GuiWindow
            {
                ...
            }
        }
    }
}

然后Workflow module支持吧編譯后的型別和指令都序列化成二進制，那么只要我把這個二進制放進資源里面，那你把編譯后的GacUI XML Resource加載進來，反射出這個path::to::my::MainWindow的類然后呼叫它就可以了，至少這樣把編譯XML的時間拿掉了，啟動速度大幅增加，

但是這樣又帶來一個問題，那我想用C++給buttonOK掛事件怎么辦？于是我給GacUI的一些類加上了一個叫做GuiInstanceRootObject的型別，這個型別現在還存在，只是功能跟當初完全不同了，主要的想法是這樣的，當你創建一個UI資源的時候，你從<Window>開始時比較合理的，但是從<Button>這樣的東西開始就有一點無稽之談的感覺了，所以我規定了只有Window、CustomControl、TabPage和XXXTemplate（當時還不存在）等等這樣的型別，才能作為XML的根節點，于是我就多了一個地方，可以把所有標注了ref.Name的物件都存進去，那么你仍然可以對著MainWindow查詢一番buttonOK，然后強制轉換成GuiButton，掛上事件，

4. 把Workflow編譯成C++，大幅縮小exe體積

于是到了這里，我終于可以做出擺脫反射的重要一步了，就算你不需要在你的應用程式里面編譯XML，那還是要把編譯后的腳本跑起來，就免不了反射，為了完全脫離反射，那么就連腳本都不能跑，唯一的方法就是把Workflow編譯成C++了，今天的GacUI，把這樣的XML，翻譯成了這樣的C++代碼，細心的讀者可能會發現，編譯出來的C++代碼里仍然包含有注冊反射的內容，不過我把它單獨分離到一個檔案里，就是為了讓想用反射的人可以用反射，不想用反射直接當這幾個檔案不存在就好了，而GacUI源代碼的設計，會讓你打開VCZH_DEBUG_NO_REFLECTION的時候包含了反射的代碼就有編譯錯誤，而不打開VCZH_DEBUG_NO_REFLECTION的時候不包含反射代碼也有編譯錯誤，讓你時刻知道自己的程式里到底有沒有反射，而不會因為巧合而做出決定，

具體Workflow怎么翻譯成C++我就不在這里羅嗦了，Workflow也是一門只有智能指標而沒有垃圾收集的語言，所以實際上只要翻譯出來的語法和語意都對上就好了，沒有什么特別困難的地方，在生成的代碼里可能大家會發現我大量呼叫了::vl::__vwsn::This函式，Workflow的語意會讓你呼叫object.Method的時候，如果object是null就當場拋例外，跟C#一樣，而C++顯然是沒有這個功能的，所以我只好把這段邏輯放進::vl::__vwsn::This函式里，而生成的代碼之所以這么長，是因為我在每一個地方都使用了包含所有namespace的全名，咋一看會比較亂，

到了這里，buttonOK如何用C++掛事件的事情就得到了完美解決，只要你給<Window>寫上了ref.CodeBehind="true"，然后ev.Clicked不要用-eval而是直接賦值一個函式名="buttonOK_Clicked"，那么GacUI就會單獨為這個UI生成一對C++代碼，在生成的代碼里就有這樣的內容：

void MainWindow::buttonOK_Clicked(::vl::presentation::compositions::GuiGraphicsComposition* sender, ::vl::presentation::compositions::GuiEventArgs* arguments)
{/* USER_CONTENT_BEGIN(::path::to::my::MainWindow) */
}/* USER_CONTENT_END() */

在這兩行里面的代碼是不會被覆寫的，而修改了其他地方的代碼則會被覆寫，體驗就跟上個世代的經典UI庫一樣，

既然Workflow module已經變成了C++，那就不存在加載程式的時候執行腳本的這個程序了，跑的全都是C++，自然也不需要反射，而且資料系結的運算式由于從腳本變成了C++，不僅性能提高了很多，而且崩潰了也能夠利用VC++當場除錯，不過前提是要熟悉C++代碼是怎么生成的，不染可能不知道這段C++代碼對應的是腳本里面的什么內容，

5. 使用MVVM

到了這一步，MVVM就手到擒來了，在上一段的例子里面，就有一個使用MVVM的HelloWorld程式，宣告一個ViewModel，也就是在XML里面用Workflow宣告一個interface，生成代碼后它會變成一個C++的abstract class，你只要用C++實作它，new出你的視窗的同時交給他，那么剩下的資料系結的作業都由XML來完成，

GacUI允許的系結多種多樣，樹形既可以是一個物件，也可以是一個集合，甚至還可以是一棵樹，這使得MVVM的理想可以被完全實作：

ViewModel包含了UI的邏輯，卻不包含UI，可以被單獨進行單元測驗，
View既可以是UI也可以是單元測驗，
UI作為一個View，只有薄薄的一層，幾乎都用宣告式語言來寫，引入錯誤的可能性不高，
復雜的UI特效則通過在XML里面使用Workflow來完成，ViewModel可以被mock，所以UI部分也可以單獨測驗，有利于分工合作，

不過由于缺乏GacStudio，想讓非專業程式員來開發GacUI的UI目前難度還比較高，這是2.0要做的事情之一，

尾聲

由于時間久遠，記憶都比較模糊了，為了寫這個博客的系列，我又重新把以前的代碼翻了出來，一開始GacUI只是作為編譯器的一個side project出現，代碼隨便放，后來由于內容逐漸增多，我把它單獨拿了出來放在了Codeplex，后來眼看Codeplex就要涼了，所以又把他同步到了Github上，后來發現同步還是有點麻煩，于是干脆挪到Github上開發，后來隨著GacUI的內容越來越多，單獨一個repo顯得有點臃腫，于是干脆開了一個vczh-libraries organization，現在這個organization里面東西應有盡有，有做了一般的Linux移植XGac，有基本已經可以在macOS上跑起來的iGac，甚至檔案網站WebsiteSource和用來index并生成GacUI檔案頁面的C++編譯器前端Document都在里面，

GacUI近兩年進度比較緩慢，主要就是花了很多時間補充檔案，還有開發這個C++編譯器上了，現在已經可以在檔案網站上閱讀GacUI的很多資料了，一開始進目錄看檔案，不過檔案畢竟不是源代碼，具體到一個函式到底多少個引數分別是什么型別指標是裸指標還是智能指標這些細節，就可以在生成的C++檔案上看到，而如果這樣還不滿足的話，你甚至可以直接在網站上看到GacUI的源代碼，這個源代碼頁面的開發嘔心瀝血，任何識別符號都可以朔源，這還是歸功于花了兩年寫的C++編譯器前端，如果這樣還覺得有點難懂，還有大量的例子等你來看，

19年之前是基本沒有檔案的，而又不少人只通過閱讀這些例子就基本掌握了GacUI的使用方法，而且GacUI的設計并沒有多濃厚的C++味道，反而有利于很多熟悉其它語言的程式員來使用，甚至還有macOS的移植就是兩個網友在完全沒有檔案的前提下，甚至不需要問我多少問題，就把他做出來了，這讓我感覺這么多年學習編程并不是浪費的，自己做出來的設計切切實實地做到了程式員友好，也是對我多年來努力的肯定，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/287091.html

標籤：AI

上一篇：漫畫 | “道德淪喪”的程式員 !

下一篇：為什么微服務并不是越早越好？