canonical

目前我們主要基于witrix研發行業軟件，本身并無意推廣witrix平臺。現在witrix所承載的核心應用對它的靈活性和性能都有著很高的要求。
1. witrix技術的創新之處在于提供了程序結構的新的抽象和融合方式，它所帶來的價值主要是程序的持續改進能力。在公司里我們是嚴禁拷貝粘貼的。可以重用的業務邏輯總可以抽象為某種技術實體。
2. domain specific的語法我們認為非常重要。很多人傾向于使用非常強大的語言，這種語言允許構造所有復雜的局部結構，但是在我們看來，再復雜的通用語言也無法涵蓋各異的業務邏輯，而語言本身提供的抽象能力至關重要。同時我們還非常關注于抽象出的技術結構的穩定性。假如做一件事情有n種語義等價的方式，而且沒有一種強制手段可以進行形式校驗，則任何一種抽象得到的結構都是不穩定的，因為我們總是會受到各種誘惑偏離一種固定的形式，最終造成形式的解體。
3. 我們在編譯期作了很多工作，這是解決系統結構問題的一種重要手段。在沒有得到全部信息的情況下（沒有運行時的數據信息），即使沒有類型概念，我們仍然可以在結構方面作很多文章。
4. 現在很多情況下其實是沒有很好的抽象方式。比如說，如果把位圖的每個像素都看作一個具有自我活動能力的對象，我們遇到的問題首先是巨大的管理成本，這遠不如把它看作只接受外部控制的數據信息更直觀，更簡單。一些所謂優雅的設計只是在最模糊的印象上似乎很時尚， 但是真正細致到細節的時候，它遠不能提供我們所需要的結構控制能力。
5. 代碼是交流的重要工具。witrix設計的一個重要目標就是代碼的可描述性，編碼的過程就是描述系統結構的過程。我們正在盡力縮小需求描述與代碼結構之間的概念差距。但是很多時候代碼是信息不完全的，有些信息我們寫在了代碼之外的文檔中，特別是一個設計的原因是什么，為什么采用當前的處理方式。
6. AOP的原始形式存在一些隱蔽的問題，直接應用AOP效果是有限的。在witrix中我們是對AOP的概念體系進行了補充，才定義出足夠強大的結構組合方式。
7. 對程序員來說代碼更加便捷，但是工具仍然是有效的，它可以限制程序的可能性，大大提高我們構造某種業務流程的可靠性。
8. 商業是一方面，人的精神和傳統是另一方面。
9. witrix目前就在運行時管理著大量的代碼版本，繼承只是一種初級的結構融合手段。

對設計有興趣的朋友可以通過 canonical.cqh@gmail.com聯系我

我是在講語言，講的卻是語言之外還有別的

我一直在講物理，你現在來和我講數學。。。

描述和解決能是一回事嗎? 我寫下一個方程,這叫描述. 求出它的解, 這叫解決.

sign, 很遺憾你這么想問題。 我在很認真的回答你的問題。因為這個問題有多個人問過我，所以寫一篇文章。

我的專業是物理。在我本科的時候，我主要在讀更多的物理和數學，而不是掌握具體的語言技術。 大四的時候我讀了圖書館可以找到的大部分C++書籍。當然我更多的時間仍然是花費在數學和物理上，因為原本我就是打算去做理論物理研究的。

我的意思是基礎很重要。大三之前都是學習最基礎知識的時候，專業的限定并不是很大。在我們學校，大二各個系開的課都是類似的，只是難易，重點不同。 你年齡太小，還區分不出什么是真正重要的東西。 其實即使是電路分析，你搞清楚里面的物理和數學也是很有意思的。絕對不是讓你按照考試的要求學習書本上的知識。

學習并不是為了有用，它只是讓你接受教育，了解歷史上人們所做過的一些工作。

溫和的感想和例子未必是對你有用的。你還沒有受過挫折，只是一味要求別人順著你的心情。我寫的東西如果你放棄成見體會一下，也許會發現并不是那么差。

高手不高手并不重要，關鍵是成為別人可以信賴的人，成為一個可以解決問題的人。

1. 語言中的時間觀念這個論題絕對不是我的原創
2. 我一直強調思維的連續性。不是說"B這樣搞來搞去還是達不到A的高度"， 而是說我們如果把系統的特征逐個分解，到底需要做哪些工作才能逐步增加最有價值的部分，特征聚集產生的增值部分又是如何顯現的。
3. 一種實現總是包容了太多的思想。思想錯了，實現對了。實現死了，思想活著。

在Witrix中我們系統化的應用[面向集合+通用組裝規則]的技術手段，大大提高了代碼的重用性

從指針到引用，雖然在C++中顯得只是寫法上的簡化。但是仔細體會能夠發現概念層面發生的一些變化。我們不再依賴取址這個具體過程，而在某種符號化的層面上理解引用所表達的信息關聯。耦合不是一個合適的描述。

你還是不懂得

1+1=2只是個形象的說法，它可不是歌德巴赫猜想的內容

在數學和具體工藝之間還存在著所謂的物理學，這就是Witrix設計的方向。

我想你對Witrix技術還不了解。我在blog中所闡釋的理論一般都是在Witrix中實踐了的，這些技術包括AOP動態化，基于ORM的實體化等都是Witrix中對開發效率有重大提升的地方。 目前很多技術在業內確實處在一種言過其實的地步，而我們在理論方面有很多突破，而在具體實現上也作了很多精細的調整，這才最大限度的發揮了技術的效用。

開發工具并不一定是生產力的主要來源

JSF技術有一些真正有價值的東西，但是根據我們的實踐，這些價值有其他更加優雅的體現方式。 JSF不是必須采用JSP Tag, 但是它需要一種類似的技術，而它在架構設計中必然要照顧到這種技術實現。 其實witrix中的tpl技術也是一種tag技術，只是它遠比jsp tag要精致。

JSF架構最大的問題就是開發新組件很麻煩，完全基于JSF構建程序很繁瑣，最終提供給用戶的調用接口其實也有更加簡明的方式.

關鍵正在于reference這個概念本身的分化和精細化

沒有人認為核心對分支完全不影響，否則核心升級就沒有任何意義。只是升級是可選擇的，而且分支可以選擇整體覆蓋，即擴展后整個流程A->B->C都屬于分支

分支版本可以是不同的產品，不一定是同一產品的不同實施版本。在設計上的要點就是盡量允許主系統升級后可以隨意覆蓋項目版本，因為項目版本針對主版本的修改是以追加方式進行的，即并不直接修改任何主版本的文件，而是寫在獨立的文件中，平臺負責把custom內容和基礎版本內容融合。如果分支版本完全需要采用新的實現，平臺提供了完整的替換機制，同時可選擇是否校驗接口的兼容性。

witrix中meta的思想與一般人的第一感覺還是有著本質區別的。在witrix中，典型的開發過程是通過powerdesigner設計數據模型，然后自動生成meta數據，此時對于數據庫的增刪改查就可以進行了，包括對于one-to-one,one-to-many,many-to-many等關系的維護，高級查詢條件的拼裝，導入導出功能等。這些設計因為基于ORM模型，因此并不是僅僅針對單表的，而是可以很方便的處理關聯表的情況。
如果界面沒有特殊要求，一般最多調整一下meta中字段的屬性。如果完全要求定制布局，則在前臺通過<df:Field name="fieldName"/>等標簽引入字段元數據，增刪改界面可以共用一個定制頁面。而后臺依據meta對前臺提交數據進行初步處理。在witrix的開發過程中，幾乎不需要調用get/set方法，也不需要調用session.save, session.update等方法，前臺也幾乎不編制完整的界面。

to mixlee: 我們目前無意成為平臺軟件供應商，因此不對外提供witrix的資料。

Workflow中需要頁面和流程配合的部分在Witrix中主要通過前臺js選擇實現，流程引擎實現的是事件響應而不是驅動界面。 這里倒不太用得上我所謂的PageFlow。 實際上我是反對基于action的flow設計的。

我所寫的一般都是理論分析,并不是針對初學者的介紹性內容.
AOP是一種很少限制的結構操縱技術, 你可以去想象它的應用

數據到底是保存在session中還是request中，對于這個問題，基本上它的答案就是應該保存在哪里就保存到哪里。 對于一般簡單的網頁，應該少在session中存放變量，而對于復雜的企業應用，在session中保持狀態是必要的，不過查出的數據一般放在request中就可以了。

一種flow關注的重點當然是協調某種類型實體之間的動態關系，這其中必然需要一種機制來保持狀態信息。PageFlow肯定需要一種大于request而小于session的狀態保持機制. Jsplet框架就提供了這種機制，而PageFlow是運行在其上的一個引擎。

嗯，我們對hiberante作了一些擴展，包括支持公式字段，附件上傳字段等

使用hibernate不是為了從面向對象的觀點思考設計系統這種純學術性的目的，而是為了更快更好的解決我們所需要面對的問題。 witrix平臺中對于hibernate的使用是相當深入的，包括對于hibernate的多處hack.
我們需要模型是因為我們需要一種控制力， 不在于是否native. 從物理模型恢復邏輯模型比較直接，并不復雜， 而且我們并不試圖恢復整個邏輯模型，而是得到我們所需要的信息即可。
面向對象是什么？ 首先它是一種相關性的聚集。

@OneEyeWolf
如果你有興趣, 應該讀一讀我其他的文章, 以搞清楚我在說些什么.
http://canonical.blogdriver.com/canonical/961298.html

operator的設計正在于它的可擴展性不夠.

設計的實現方式是設計的內容之一

@OneEyeWolf
具體實現的策略就是 CRUD + Filter, 我已經寫得非常清楚.

我們的bizflow實現是基于tpl技術的，而不是使用operator的概念， 那樣太受局限了。

bizflow是由biz object 驅動的流轉，而不是由步驟的先后順序驅動的流轉，所以它不是完整的工作流。

簡單的bizflow可以滿足眾多不需要分支的流轉需求，這已經足夠做一些有意義的事情。

對于事件機制不是設計而是描述。

行為之間的順序也是結構, 結構這個詞的含義是非常寬泛的, 我所指的并不是數據之間的關聯,而是泛指關聯及關聯的集合.

雖然我說過很多遍,但我相信大多數人仍然沒有明白我所指的在復雜性級列之間過渡的含義. 正如我常說的, 一個人只理解他已經理解的東西

沒有這樣的計劃

架構師之家是什么. blog帳號 canonical

jsp tag最核心的設計問題在于它所假設的模型是動態io處理，而缺乏對于xml結構的充分利用。對于具體的表現， 我已經在一篇blog中作了評述。
http://canonical.blogdriver.com/canonical/572201.html

應該是走高而不是走低。集成的需求促使復雜性上升。