1 對于類型是checkboxgroup的數據，數據庫中保存數據的格式是value1,value2...valueN，其中1~N的數據有可能不存在，如果選中則存在，最后拼接成一個串。
在Ext中，通過Record對象向FormPanel中的內置對象BasicForm加載數據時，采用的是setValues方法，而setValues第一步要通過Record中定義的name使用findField方法找到表單元素，遺憾的是，繼承了Field的checkboxgroup組件并不能正確的通過getName返回自身引用，所以，需要對getName方法進行重寫，此外，為了適應我們采用的數據格式，對于該組件的setValue（被setValues調用）和getValue（獲取到已加工的數據，此事后話）也要進行重寫。故而對于形如：
{
xtype: 'checkboxgroup',
name: 'biztype',
width: 220,
columns: 3,
fieldLabel: '業務類別',
items: [
{boxLabel: '類別1', inputValue: '01'},
{boxLabel: '類別2', inputValue: '02'},
{boxLabel: '類別3', inputValue: '03'},
{boxLabel: '類別4', inputValue: '04'}
]
}
的checkboxgroup定義，需重寫類如下：
Ext.override(Ext.form.CheckboxGroup,{
//在inputValue中找到定義的內容后，設置到items里的各個checkbox中
setValue : function(value){
this.items.each(function(f){
if(value.indexOf(f.inputValue) != -1){
f.setValue(true);
}else{
f.setValue(false);
}
});
},
//以value1,value2的形式拼接group內的值
getValue : function(){
var re = "";
this.items.each(function(f){
if(f.getValue() == true){
re += f.inputValue + ",";
}
});
return re.substr(0,re.length - 1);
},
//在Field類中定義的getName方法不符合CheckBoxGroup中默認的定義，因此需要重寫該方法使其可以被BasicForm找到
getName : function(){
return this.name;
}
});
2 通過內置對象basicForm的getValues方法可以獲取到一個form的完整json數據，但遺憾的事，這里取到的是dom的raw數據，類似emptyText的數據也會被返回，而Field的getValue方法不存在這個問題，所以如果想要返回一個非raw的json集合，可以給formpanel添加如下方法：
getJsonValue:function(){
var param = '{';
this.getForm().items.each(function(f){
var tmp = '"' + f.getName() + '":"' + f.getValue() + '",';
param += tmp;
});
param = param.substr(0,param.length - 1) + '}';
return param;
}
這個方法同樣適用于上面定義的checkboxgroup，如此就可以把前后臺的數據通過json統一起來了
摘要: 當前的富客戶端可以包含兩部分：分別為JSP頁面和通過富客戶端js組件（如extjs）渲染的組件化窗口頁。針對這兩部分分別做如下處理：
對于JSP頁面的部分采用JSTL標準庫的fmt標簽，如通過：
<fmt:message key="page.login.title"/>這樣的形式進行展現，其中message對應的文本在服務端配置，并在web.xml中配置資源文件的位置，也可以采用s...
閱讀全文
看此文前請保證jar包中有至少一個Main方法入口，及圖形化的界面。
并保證META-INF/MANIFEST文件中的Main-Class已經指向之前實現的main方法入口。
最近硬盤壞了，于是重新安裝了OS，發現拷貝后的jdk或jre（未經安裝的版本），不能打開jar文件執行（jdk版本1.6_11），
于是在打開方式中指向了javaw程序，發現無效，并提示"cannot find main class", 與此同時windows把jar類型的文件關聯到了
指定的javaw程序上，上網找了一通，沒有人提及這個問題的解決辦法，而顯然這個問題又不是由開篇中提到的問題導致的。
于是在注冊表中當前用戶配置中刪除了當前jar類型的定義。但是重新嘗試后依然無效。
于是重新安裝了jdk，發現這次可以打開jar文件了，并且這次用來打開的程序從打開方式來看仍然是javaw。
比較注冊表中文件類型的定義，并沒有差別。從文件夾選項 -> 文件類型來看終于看到了差別，
高級里面的open操作定義如下：
"C:\Program Files\Java\jre6\bin\javaw.exe" -jar "%1" %*
而如果我們自己選擇javaw，默認的open操作是沒有 -jar參數的，必須手工加進去。
我們知道java啟動jar包的參數是 -jar，但是記得以前javaw是可以直接打開jar的，不知什么時候起也需要帶有-jar參數了。
所以對于一個拷貝的綠色jre只要修改一下open操作的定義就可以解決上面的問題了。
解決了上面的問題，又產生了新的問題，之前選擇打開的javaw程序在打開方式中丟不掉了，比較多余，這個可以在注冊表中修改
在HKEY_CLASSES_ROOT\Applications下面找到響應的程序刪除就可以了，原來每次用一個程序打開一個類型的文件windows都會在
注冊表中這個地方留下相關的記錄
偶然間注意到一個困擾了我很久的問題，那就是如果我不通過Socket而通過應用層的某種基于文本的協議，比如SOAP進行通信的話，
如何傳遞二進制的數據呢？現在SOA，Web Service等很火，應該會遇到這種問題吧？
現在已知的方法可以通過Base64進行編碼，其原理和方法見：
http://baike.baidu.com/view/469071.htm
這種方法采用了字節中的6位進行文本轉換，并且在其他論壇上也看到了帖子說淘寶的搜索也采用了這種編碼方式進行處理。
但是采用了5位進行轉換。并且大膽地給出了5位轉碼的算法，見：
http://www.javaeye.com/topic/286240
不過這種5位的轉換會產生更多多余的字節，6位的轉碼充分利用了現今的可讀文本，可是5位卻沒有，因為5和8的最小公倍數是40，
所以當每轉換40位即5個字節的二進制數據需要8個字節來表示，這樣就多產生3個字節，浪費的效率是3/5, 而6位轉碼浪費的效率是
1/3。而且隨著字節增多，轉化效率也在下降。可見采用5位轉碼是一種既浪費空間，又浪費效率的解決方案。在不增加url長度的情況下充分提高效率，6位編碼是最佳的。如果可以任意的餓犧牲url長度，
可以把0-9全部拿出來當做標記位，0-9不會單獨出現，這樣一共有10*26 + 26 = 286 種可能還不包括小寫字母，
此外還有=，+，-什么的至少256可以編碼8位的字節了，這樣處理效率就提高了。
現在把問題優化一下，人類可讀無歧義的文本碼有0-9，A-Z,a-z共62個
設取出x個作為標志位則(62-x) * x + (62 - x) >= 256
解這個二元一次方程得到:
3.366<=X<=57.634
考慮到編碼的文本長度，取x的最小值，即 4
最優解：
用0, 1, 2, 3做為標志位
4-9，A-Z, a-z參與編碼并與標志位配合實現8位字節的文本化
可以看到這種方法的轉碼效率會比較高，但是空間冗余大。
此外其實可用的文本不知62個，包括感嘆號等用上后補足64 = 2^6
它的高位是 00
那么只要再找到三個文本符保存其他三個高位01 10 11就可以了
這樣的轉碼空間可以更小一些。
想法還很不成熟，歡迎大家批評
摘要: 最近在學習JavaScript，發現不論是ext還是prototype都很推崇json這種通信協議的格式，但是這兩個框架都是比較偏前端的，和dwr不同，dwr是一個一站式的ajax框架，不僅提供了客戶端的工具方法，也包括服務端的配置和通信的處理。
而ext和prototype等僅僅設置好了json的接口并對ajax通信做了封裝，相對而言是一種比較“純粹”的AJAX實現，當...
閱讀全文
學過軟件工程的都知道，軟件產品的生產周期是一個經歷若干階段的漫長過程，包括需求獲取 - 設計 - 開發 - 維護等等。
需求階段 - 總想考慮到所有的問題，或是一切按合同辦事。但在現實中根本不得能，因此很多公司開始提倡“隨需而變”的能力，希望快速的響應用戶的需求變化
維護階段 - 總希望自己開發出來的東西一勞永逸，永遠不要再產生任何麻煩，產生了麻煩也不要找到我。甚至有些項目組的人員開發出來一大堆不成熟的產品、項目后撒手不管，走人了事，毫無職業操守，亦是對自身行業聲譽（至少是國內IT服務提供商聲譽）的一個打擊。真正的項目開發不應該這樣，一定是非常易于維護的，能夠快速地找出問題的所在，或是新需求切入點的所在，然后解決
很明顯，前面提到的兩個問題都要也只能通過設計和開發來解決。問題來了，怎樣開發出的軟件才能快速地響應需求，易于維護？可以有很多不相沖突的說法，比如解耦，比如通過POJO封裝數據等等。這些東西流行開來以后，很多人有疑問，為什么我的項目中一定要用這些框架？我不用這些框架也可以快速的開發出我要的功能，而且更加簡單，等等。如果孤立地從設計和開發的角度看這些問題，這種說法并沒有錯誤，但是如果從整個軟件開發的生命周期來看，則不是這樣。當然，這里還有一個是否“過度設計”的trade-off在里面，不過那又是另一個話題了。
再說說各種各樣的平臺吧，它們和框架不同，軟件體系結構中有一種架構模型即層次模型，我們現在的TCP/IP協議棧即屬于這種模型，我們的軟件對于平臺產品的依賴是一種朝向穩定的依賴，就好像我們在調試代碼時往往不會去調試操作系統API的bug一樣，因此在開發這種平臺層次級別的產品時就沒有必要再去采用那些為了保障“企業應用”Web軟件生命周期中所采用的方法了，完全可以用最基礎，最底層的手段。只要能夠做到高效、穩定即可。因此，平臺中間件產品的開發必須和應用軟件產品分開來看，雖然它們可能都在用Java這種編程語言。
本科讀書時，曾聽過離散數學老師一句很精彩的論斷：“只要能夠形式化的東西，就可以自動化”。可是今天我不談離散數學，倒想說說其他不相關的東西。
你一定聽到過“一流的企業賣標準，二流的企業賣品牌，三流的企業賣產品”。
什么是形式化？為什么形式化的東西就可以自動化呢？撇開數學符號不談，對企業來說，形式化的東西可以是一些規章及做事的方法，生產產品的方法等等。為什么人民幣稍一升值，中國的中小制造型企業就要痛苦不堪？因為我們每既沒有品牌，更沒有標準，拿生產DVD機為例，最初的90年代生產DVD機賣到歐美很賺，可是現在據說不賠錢就不錯了，因為要繳納一大筆的專利費。中國的大多數企業處在整個產業鏈的最下端，所得的利潤的大多數被其他企業剝奪了，因為我們用的是別人的品牌，別人的標準。我們的公司在全球經濟中處于“民工”的境地。
回到我們的問題中來，一流企業所做的標準，是生產一種產品的方式和規約，這一層面是抽象世界的最高層次，無法對這層抽象的產生進行形式化，所以是一種創造性的勞動；二流企業所賣的品牌是對一種產品具體生產方法的規約，通過“模板方法模式”的應用，這一層次的抽象的模板可以從上一個層次的形式化中自動化，然后只需形式化具體的操作細節，對于生產細節的形式化，也需要一定的創造性的勞動；三流的企業是一部機器，因為到此為止一切的東西都已經形式化了，只需要有時間和精力的機器去自動完成而已。
讓我們好好想想在一個知識經濟的社會里，什么事物是創造性的，是只能被形式化而不能被自動化的。因為只有人類的創造性思想不能被機器所取代，這也是為什么機器人無法取代人類的原因。
80年代出生的人應該記得歷史教科書中的論述，工業革命時，一些工人去砸毀機器，覺得這些機器剝奪了他們的工作。如果有一天，老板突然來告訴您：你可以離開了，請不要沮喪和懊悔，因為您早該意識到您其實就是一部機器。當然為了防止上面悲劇的發生，早點去從事有創造性的工作吧，停止對于各種軟件自動化輔助工具的抱怨和擔憂，勇敢地迎接明天。
還記得小時候常看的電影《神鞭》吧！
偶然間看到下面有一個網友慨嘆普元的強大，而開發人員的渺小。
小弟剛剛參加工作，也在項目中接觸到了普元的EOS。普元的這個東西怎么說呢，就是亂用XML然后Spring沒做好就變成那個樣子的，同時失去了類型的表述，一部機器要進行裝配需要組件和零件，軟件應該自上而下，分而治之，這是上個世紀70年代，學者們就達成的共識，所以關于“銀彈”神話的唯一結論就是——“沒有銀彈”。
為什么說EOS是沒有做好的Spring？
Spring簡化了對象的裝配，強調重用，是建立在面向對象基礎上的，是建立在敏捷測試基礎上的，是建立在強類型基礎上的；
而EOS則是建立在面向過程的基礎上的，建立在不可測試的基礎上的，建立在毫無類型基礎上的（全是String）
然而EOS也有很多的優點（據小弟不完全發現）：
1）EOS固化的開發流程強制一個team從一種易于維護的結構組織Web，包括頁面，表示層，邏輯層等等。否則的話就需要一個架構師來做出規約，但仍不易于管理；
2）EOS的畫圖功能讓人耳目一新，從“代碼即文檔”的哲學出發，這些畫圖很好地詮釋了代碼表述的內容和結構，給程序的維護帶來便利。
3）相對于OO和J2EE傳統開發，EOS易于上手，學習曲線較短。但是這一點有爭議，EOS的知識不具備通用性。
綜上，根據2-8的關系法則，在某些領域EOS的確有其優點，但是認為EOS完全“解放”了程序員，則是不負責任的說法。
這只是我的個人看法，歡迎大家就此話題討論。
聯合國是國家間的標準化組織，可惜一超多強們只把它當作是一個道具，需要時拿來用一下，不需要時完全可以踢到一邊。
歷史上，每個朝代都認識到失敗的教訓，卻最終都迎來了相似的結局。
有人說，軟件行業是一個天生的壟斷行業，其特質是，產品研發的過程異常的復雜，但產品一旦出爐，就可以瘋狂而不計成本地生產。只有NRE Cost，眼下的軟件行業也出現了群雄逐鹿的場面，上游產業被幾家大公司所瓜分，這些大公司如果能互相牽制，則會坐在一起，成立一個組織。如果一家獨大，則我行我素，稱王稱霸。
看看他們的一路成長：
初始：
他們想占有你，最初都會很乖。就像女孩在成為家庭主婦之前總能收到男孩的禮物。
成長：
大公司們也漸漸從規范的參與者，變成規范+的樹立者，比如IE，Office，再比如Oracle的特性等等。
稱霸：
市場占有的差不多了，可以不顧客戶的意志做自己喜歡的事情，反正你已經離不開我。
消亡：
客戶們怨聲載道，新的“符合規范”或簡潔明了的產品出現市場。
希望這些大軟件廠商們能夠吸取教訓，也希望小軟件廠商們將來不要走入歷史的怪圈。