最近要做一個Python的基于Eclipse的界面設計器，因此我對各種GUI設計工具做了一下分析，發現GUI設計工具也有一個門派。
在那個懵懂的年代，一切界面代碼都是要開發人員手工書寫，這無疑增加了開發難度，Delphi、VB等工具的出現扭轉了這個局面，使用這些工具開發人員只要在控件面板上拖拖拽拽就可以完成界面的設計，做到了“所見即所得”的開發方式。仔細分析，GUI設計工具有如下幾個門派：基于界面文件的純代碼生成、代碼生成與界面文件結合、無界面文件方式。

基于界面文件的純代碼生成：NetBeans是這類工具的典型代表（如果我沒記錯的話JBuilder也是這樣實現的），NetBeans中與界面設計有關的有兩個文件：.java文件和.form文件。.form文件中是以XML格式描述界面布局和控件的屬性等信息；.java文件則是通過解析.form文件生成的代碼，生成的界面代碼主要位于initComponents方法中，這個方法在NetBeans IDE中是無法手工編輯的。在用戶拖拉控件的時候，NetBeans就將拖拉的控件描述增加到.form文件中，并且即時將新的代碼生成到.java文件中。這樣實現的好處有如下幾點：IDE實現容易，IDE的開發人員只要關注于如何將界面信息轉化為.form文件和如何將.form文件解析生成.java代碼即可，無需關心用戶修改.java代碼造成的反向解析問題；.java文件可以脫離.form而存在，也就是.form文件只是在設計期有意義，而在運行期是無用的。缺點是：用戶無法手工修改生成的代碼。
代碼生成與界面文件結合：Delphi和VB是這類工具的典型代表。以Delphi為例，在Delphi中新建以后界面以后將會存在兩個文件：.dfm和.pas，.dfm描述了界面布局和控件的屬性等信息，.pas則定義了控件的變量和事件處理函數。在編譯的時候.dfm被編譯到可執行文件中，運行的時候動態解析.dfm文件來構建界面。與NetBeans不同的就是.dfm文件是有運行期的意義的，如果沒有.dfm文件文件，程序將無法編譯運行。這樣的方式通常只適用于Delphi、VB這樣代碼和IDE結合過于緊密的語言，很難將生成的代碼進行手工修改。
無界面文件方式：Eclipse的Visual Editor是最經典的例子。使用Visual Editor進行GUI繪制的時候，只存在一個.java文件，Visual Editor將用戶繪制的界面直接解析為.java代碼，如果用戶修改了.java代碼，Visual Editor會運行一個虛擬機，在虛擬機中運行用戶修改后的文件，得到運行時的程序界面，然后將這個界面繪制到窗口設計器中。這樣做可以將所有的界面信息都集成到一個文件中，并且支持用戶手工修改生成的代碼；由于設計器中的界面是通過另外一個虛擬機運行而得到的，在界面設計器中看到的界面就是運行時的界面，這樣保證了真正的“所見即所得”。這樣做的壞處也是明顯的，由于需要重新啟動一個虛擬機，導致了速度很慢，資源占用比較高，使用Visual Editor的時候經常造成Eclipse內存不足退出。

我在開發界面設計器的早期采用的基于界面文件的純代碼生成方式，系統中有一個.aui文件和對應生成的.py源代碼文件，后來由于系統需求（主要是要求允許開發人員修改生成的代碼），我就準備改用無界面文件方式。如果采用Visual Editor的無界面文件方式難度是比較大的，而且會導致資源占用太大，因此我采用了另外一種思路，也就是在內存中為每個界面維護一個對象模型（樹狀結構），在用戶繪制界面的時候去修改這個對象模型，在用戶保存界面的時候去解析這個對象模型生成.py源代碼；在由.py源代碼加載繪制設計器中的界面的時候，首先通過解析.py 源代碼生成源代碼的抽象語法樹（AST），然后解析這個AST生成界面的對象模型，這樣就可以很輕松的繪制界面了。這樣做不僅有Visual Editor的優點，而且占用資源比較小；不過由于手工修改代碼的千差萬別，如果開發人員修改的代碼采用了比較生僻的語法，有可能造成用戶修改的代碼無法正確的解析為對象模型，造成.py源代碼加載繪制設計器中的界面的時候發生異常，解決這個問題的唯一一個辦法就是建議開發人員盡量采用常用的代碼來修改生成的界面代碼。
由于HTML代碼本身就是一個樹狀模型，無需進行代碼和模型間的轉換，所以網頁設計器就不存在上邊說的這些幫派了。