canonical

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

對設(shè)計有興趣的朋友可以通過 canonical.cqh@gmail.com聯(lián)系我

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

我一直在講物理，你現(xiàn)在來和我講數(shù)學(xué)。。。

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

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

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

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

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

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

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

1. 語言中的時間觀念這個論題絕對不是我的原創(chuàng)
2. 我一直強調(diào)思維的連續(xù)性。不是說"B這樣搞來搞去還是達不到A的高度"， 而是說我們?nèi)绻严到y(tǒng)的特征逐個分解，到底需要做哪些工作才能逐步增加最有價值的部分，特征聚集產(chǎn)生的增值部分又是如何顯現(xiàn)的。
3. 一種實現(xiàn)總是包容了太多的思想。思想錯了，實現(xiàn)對了。實現(xiàn)死了，思想活著。

在Witrix中我們系統(tǒng)化的應(yīng)用[面向集合+通用組裝規(guī)則]的技術(shù)手段，大大提高了代碼的重用性

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

你還是不懂得

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

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

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

開發(fā)工具并不一定是生產(chǎn)力的主要來源

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

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

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

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

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

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

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

我所寫的一般都是理論分析,并不是針對初學(xué)者的介紹性內(nèi)容.
AOP是一種很少限制的結(jié)構(gòu)操縱技術(shù), 你可以去想象它的應(yīng)用

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

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

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

使用hibernate不是為了從面向?qū)ο蟮挠^點思考設(shè)計系統(tǒng)這種純學(xué)術(shù)性的目的，而是為了更快更好的解決我們所需要面對的問題。 witrix平臺中對于hibernate的使用是相當深入的，包括對于hibernate的多處hack.
我們需要模型是因為我們需要一種控制力， 不在于是否native. 從物理模型恢復(fù)邏輯模型比較直接，并不復(fù)雜， 而且我們并不試圖恢復(fù)整個邏輯模型，而是得到我們所需要的信息即可。
面向?qū)ο笫鞘裁矗?首先它是一種相關(guān)性的聚集。

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

operator的設(shè)計正在于它的可擴展性不夠.

設(shè)計的實現(xiàn)方式是設(shè)計的內(nèi)容之一

@OneEyeWolf
具體實現(xiàn)的策略就是 CRUD + Filter, 我已經(jīng)寫得非常清楚.

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

bizflow是由biz object 驅(qū)動的流轉(zhuǎn)，而不是由步驟的先后順序驅(qū)動的流轉(zhuǎn)，所以它不是完整的工作流。

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

對于事件機制不是設(shè)計而是描述。

行為之間的順序也是結(jié)構(gòu), 結(jié)構(gòu)這個詞的含義是非常寬泛的, 我所指的并不是數(shù)據(jù)之間的關(guān)聯(lián),而是泛指關(guān)聯(lián)及關(guān)聯(lián)的集合.

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

沒有這樣的計劃

架構(gòu)師之家是什么. blog帳號 canonical

jsp tag最核心的設(shè)計問題在于它所假設(shè)的模型是動態(tài)io處理，而缺乏對于xml結(jié)構(gòu)的充分利用。對于具體的表現(xiàn)， 我已經(jīng)在一篇blog中作了評述。
http://canonical.blogdriver.com/canonical/572201.html

應(yīng)該是走高而不是走低。集成的需求促使復(fù)雜性上升。