關注技術，關注生活

@sitinspring

你說的這個還是編碼的問題，中文取出后變成問號就是和我說的第6點一樣的問題，一般情況下有可能出現的就是你的URL中文用的是UTF-8但提交時可能把它當成GBK了，或者是GBK當成UTF-8了，這時候會有部分不出出現錯誤，但有一些會出現?或方框，這是因為UTF-8中的碼表跟GBK的不是一樣的，但有部分一樣。而出現?大多數情況下是轉成ISO-8859-1出問題，出方框是轉成GBK出問題，這部分因為要說起來會很麻煩，所以我也沒在這里面提出來，但只要你在所有地方設置好了編碼，一般就不會出現這種情況了。

還有你這種情況的出現，有時是你在TOMCAT里沒設置好編碼造成的，這個配置一下就行了的。

看來加班只能是程序員的命了，不管在大公司還是小公司里。你說的那個印度阿三實在是我等學習的榜樣啊，看來在大公司里混就要像他學習了。在小公司里怎么解決的都會被人問個清楚明白，想偷懶都不行。

基本上用過EXTJS后就不想用其它的了。

我就是用范型實現的啊，在05年時做的一個項目時就用上了，當時JDK1.5好像才剛出沒多久。一直沒發現什么問題

老弟，你寫這個東西就叫煩人啊，我每個星期都要寫幾千行的JS代碼，那我不早就跳樓算了。還有像“啊啊啊啊 ”說的一樣，struts中把styleId屬性做為html標簽的id屬性使用，這個在reference中就可以查到的了。

是2K嗎，我使用的時候，GET時只有1K，POST時好像有4K。反正沒有2M那么多，要是那么多的話，我就不用那么煩了

界面感覺有點MindJet的味道.....不過總體上感覺還不錯.

@Feng
Mock可以模擬一個環境，在重現WEB應用中的某些特殊BUG時很有用。

以此類推，類似于xml解析等的工作也沒有必要自己一步一步地用dom或者什么亂七八糟的sax自己去搞一遍，搞了半天就使為了得到其中的一個value，何苦來著?

===========================
確實不明白樓主說：不用DOM解析XML得到VALUE。這句話的高深函義，每每在項目中有需要解析XML的地方我都是用了DOM4J來解析。確實不知道有什么更好的辦法得到我想要的VALUE，還望樓主告知一二。

@江上一葉舟
1、對于所說的情況確實是存在，如果是我，我會將領導的那種一次性導入看成是另一個資源操作，而權限是對這個資源操作的設置，對普通管理員，則沒有這個資源操作的權限，就像一個頁有增加，刪除，修改，查看，導入，上傳，下載的功能一樣，增刪改查，我會看成是一個ACTION中的操作，導入看成是另一個ACTION中的操作，上傳下載看成是第三個ACTION的操作。一個頁面分離成三個ACTION的權限設置，就是這樣而已，不是說硬要認為。數據的讀取方法，過程，可以不必特別在意，抽象出來后都一樣。“獲得request流，解析流中數據，并且添加入數據庫”不過就是獲得數據，保存數據的過程，和頁面填寫數據，然后提交保存入數據庫是相似的，不同的只是過程。

2、我說的問題之前也說了它的權限設置可以看成是“對餅圖的查看操作，對曲線圖的查看操作，導出到PDF，也不過就是對PDF的查看操作”，所以對于領導的要求也是能完成的，普通管理員只有查看數據的權限，領導有查看餅圖的權限，查看曲線圖的權限。

3、當然我說的也并非是針對某一需求的理解，而是將頁面的操作進行抽象后的理解所說的。呵呵

權限有的是基于ACTION或URI，有的是基于資源的，可能你的是基于資源的，所以和我的想法并不是相同的。權限開得更清楚也不是沒有好處，至少在設置權限時用戶更加清楚它設置的權限對哪個操作有影響。
就像我一開始說的，這是我第一個項目時所想的權限系統，當時所想的也是要簡化復雜的權限系統，而沒有關注到用戶設置權限時是否清楚的問題，時隔一年，現在的權限設已大不相同，操作的定義在于XML文件中，而非數據庫或用權值表示，操作可以有十個或一百個，這都不影響，設置權限時讀取的是XML文件中的信息，它顯示用戶可以設置哪些操作，操作對應的模塊等等的信息。而設置后的相應信息同樣保存進數據庫，在用戶登陸時再進行加載。數據庫保存的就是XML文件中的模塊或操作的ID，權限具有繼承的能力，系統權限優于模塊權限等等。這些都是根據市場和自己的理解變化而變化的。只是在看到你這篇文章后令我想起了自己設計的第一個權限系統而有感而發而已，不要見怪。

@江上一葉舟
我是對你這個方法而說的：
public static boolean isValidPrivilege(int privilege)//判斷是否具有權限
27 {
28 if ( (privilege & QUERY_OR_USE_PRIVILEGE) != 0)
29 {
30 return true;
31 }
32
33 if ( (privilege & CREATE_PRIVILEGE) != 0)
34 {
35 return true;
36 }
37
38 if ( (privilege & DELETE_PRIVILEGE) != 0)
39 {
40 return true;
41 }
42
43 if ( (privilege & UPDATE_PRIVILEGE) != 0)
44 {
45 return true;
46 }
47
48 return false;
49 }
isValidPrivilege方法要是有任何一個權限都會返回TRUE，但結果與return privilege >0是一樣的。難道不是？

哈哈，沒想到你們公司的情況居然和我們的如此相似。

代碼沒仔細看，不過你的判斷是否有權限方法，感覺可以只是地判斷是否值大于1就行了，不過搞四個那么多，就像你原來所說的，如果擴展了權限，那你不是每次要加一個判斷？

1、確實沒想過這么處理，今天算是學到了。
2、是一個好辦法。
3、如果是上傳EXCEL的話，可以看成是對文件的添加操作，解析數據可以看成是對數據的添加操作，都是一樣的，文件也不過是數據存儲的一種方式，數據庫未出現之前，數據就是以文件的形式保存的，難道數據庫出現后，對文件的上傳而不保存到數據庫中就不能算是添加操作了？不要跟我說你只是讓他上傳，但上傳后是不保存在服務器或數據庫或其它的任何地方，而僅僅是能點上傳按鈕而已。
而報表形成餅圖也是一種權限的話，可以把它設置成對餅圖的查看操作，對曲線圖的查看操作，導出到PDF，也不過就是對PDF的查看操作，不過，個人認為，即然你都可以看到源數據了，餅圖，曲線圖卻不讓人看，還讓人家自己去畫不成？

PS:上面說的對權值的判斷，可以對16進制進行toBinaryString()進行判斷第N位是否為1，但如果在權限設置頁面時，用STRUTS標簽是很難進行這樣的判斷，一種方式是在頁面用嵌套JAVA的方式進行處理判斷，另一種方式是在數據讀取后，在返回前進行遍歷處理。第一種不用多說，現在還在頁面嵌套JAVA的做法已經被人拋棄了，原因就不多說。第二種自然只是在效率上有所減少而已。取舍還是看你自己了

怎么說呢，其實在以前我也考慮過你這個無限擴展的問題，但仔細一想，權限不存在無限擴展，權限基本的都是增刪改查，因為它們都是對數據庫的操作，
比如你說的上傳功能，它只不過是對上傳的內容進行增加操作，再如下載，也不過就是對上傳內容的查看操作，你有查看權限了，自然有下載功能，有增加權限了，自然有上傳功能。
再如報表，你不過是對報表這些內容的查看權限，所以不存在擴展性問題。
不要被擴展性所迷惑，我開始設計權限時也一度被8421的可擴展性所迷惑，但最后想仔細，其實也就只有四個操作而已，放成四個字段，比8421的方式容易修改，也容易知道有哪些權限，不用再進行計算。就像你說你用16進制存權限吧，如果我1表示查看，2表示增加，4表示修改,8表示刪除，那如果我進行增加操作，那你就得判斷我的權值是否是2,3,6,7,10,11,14,15，這其實是增加的復雜性，權限系統本身就很復雜了，如果在權值上面還進行人為的復雜化，而僅僅為的是不存在的擴展性，那我覺得是得不嘗失的。
如果是在小數據量時，XML文件方式不是不錯的，可惜權限本身就是大數據量的，針對這個問題其實我也想過一個解決方案：把每個人的權限放到一個XML文件中，因為針對個人的權限來說，相對還不算太大，然后用一個主XML存放相關文件的信息，而每個信息對應的就是這個人員的KEY，能唯一查找到對應的XML。這在某程度上應該可以解決XML加載的速度問題，但覺得不安全，因為XML文件很難對其讀寫進行權限控制，被人不小心刪除了或修改了，那也是一件麻煩的事，所以最終也沒用XML文件實現。

根據beanSoft的　 JSP 中 AJAX 的表單提交中文問題的簡單解決方案 - GBK 版本(原創) http://www.tkk7.com/beansoft/archive/2006/12/31/91144.html
果然可以解決，不得不汗一個，在GBK編碼下，無論如何都不能用SEND方法發送參數，而要把參數加到URL中然后OPEN，不管是GET或POST都這樣，真暈了。
使用encodeURIComponent 后的參數必須為UTF-8，如果不用的話就是XMLHTTP設置在CONTENT-TYPE中的CHARSET的編碼，獲取后可以用
new String( value.getBytes("iso-8859-1"), "utf-8")
和
new String( value.getBytes("iso-8859-1"), your_contenttype_charset)

好，馬上看看。試下能否成功

看看prototype的　Object.extend的實現吧。

要注意的是保存文件時的編碼也要調成一致的，要不也會亂碼。不過ECLIPSE好像有根據JSP頁面設置的ENCODING設置默認編碼的智能，一定也就不會有問題了

@bluesea
就像你所說的，對于成功應用和依賴于ERP的公司，能舉出例子來的確實很少，比例不行啊。

AJAX確實是個好東西，不過事情好壞都是雙面的，在我之前開發的項目中，我都是在逐步將AJAX應用添加到里面，一方面，隨著AJAX應用的增加，在許多以前無法很優雅解決的問題，都通過AJAX漂亮的實現了，另一方面，AJAX大范圍的使用，而帶出更多的問題卻是不可避免的。最明顯的問題就是維護，不管你文檔有多詳細，比起原來的開發模式，要讓一個新人很快上手卻是不容易的，特別的當JS的代碼量達到萬行以上時更是難以維護(是指公用的代碼)。而且JS的靈活性更使維護的難度加大了。

在很多應用中，AJAX不是真實需要，而是心理需要。就像ERP一樣，真的有那么多企業需要ERP嗎？買了ERP產品的企業，真正有使用的，能使用到里面大部分功能的又有多少百分比呢？但還那么多人去搞是為什么？因為是ERP一個企業的身份象征一樣，代表著這個企業有多大的實力。

客戶欠款表和客戶還款表就是一個多對多的關系，
客戶信息表可以看成是一個中間表，客戶欠款表和客戶還款表應該通過中間表進行連接，三表聯合查詢

蛤查文檔也是得在知道哪里問題才能查啊，呵呵

沒關系的，寫出來的東西就是要讓大家共同學習的，如果不讓轉載，那就沒意義了

支持

我也是在困惑著這個問題，因為我對很多主面都有興趣，但我知道如果不專一一點是沒多大成就的，現在就在為應該專注于哪一方面而煩。（測試我也是很有興趣的，只是好像很難找到適合的工作）

用過濾器不行嗎？？

沒錯,要搞定JSP的亂碼問題就得搞懂編碼,當時我和了一個月的時間去研究編碼,有些心得.

首先,亂碼問題的一個主要原因是TOMCAT,TOMCAT的核心編碼用的是ISO-8859-1(默認),所以你在頁面中怎么處理SETREQUESTENCODING,SETRESPONSEENCODING都無效,亂碼依舊,你必須在SERVER.XML文件中更改下TOMCAT的編碼,如本文提到的URIENCODING="GBK".當然你的頁面還要設置ENCODING還有SETRESPONSEENCODING(此時才能生效),而像本文中提到的
String S=new String(rs.getString("news").getBytes("gb2312"),"ISO8859_1");
是為下下策,你既然設了URIENCODING,就沒必要用這方法了,這方法是在沒設的情況下用的.

牛哥......
你太牛了,我佩服得五體投地

其實兩個人都沒有錯,只是大家站的位置不同,看到的東西不同而已.

同情ing,節衰吧,哈哈.我確實也看到很多人都說斷線了.國內的網絡整體素質還有待提高:)

最近在做一些需求分析和系統分析的工作，也在考慮這個問題，看完后覺得自己也犯了這“過度設計”這個錯。想得太多了，現在一般公司不用WINDOWS的大概沒有那么多個。

STARBUCKS倒還沒聽過，不過你說的這現象，我倒是見怪不怪了。我不知道這和管理有沒有關系，但我知道的是和現在人們心理想法和思想的轉變有關系。

泡泡回來了，我也回來了，比你晚來了幾天。加油！！

外包可能是中小企業一個比較好的方法。像我現在的公司一樣，不算是很大，但也小有規模，但畢竟資源有限，想要每個相關的職位都找到一個專家，基本是不可能的。一方面，會造成人材的浪費，因為對于中小型企業來說，需要專家解決的問題并不是很多;另一方面，雇一個專家和一個普通的員工所需要的薪金可是一個不小的落差，你一個月的純利夠雇這么多專家嗎？就算夠了，放在那浪費，沒機會用，還不如用這些資金擴大業務，或者慰勞一下為你辛苦工作那么久的員工，增加一下公司的凝聚力。


－－－－－－－－－－－－－－－－－－－－－－－－－－－－
最近我的blog地址更改了，超郁悶適應新環境中。。。。。。。。

不用謝我啦,我不過是"偷"用一下你的文章,也沒說什么有建設性的話.說得我都有點不好意思了.*^_^*

該不會是真的得獎了吧？:目

再一次借用泡泡的文章

太棒了,越來越喜歡泡泡的評論了.(搞不好一個不小心就喜歡上你了,怕怕)期待泡泡更多的評論.

對了，沒經過你同意，我就引用了你的文章，請見諒，不過我有注明出處。^_^，如有不當，請告訴我，我馬上刪除。

看過你這篇文章，我決定試試firefox,之前我一直在用IE，不為什么，只因為它方便，不用自己再安裝。