關(guān)注技術(shù)，關(guān)注生活

@sitinspring

你說的這個(gè)還是編碼的問題，中文取出后變成問號(hào)就是和我說的第6點(diǎn)一樣的問題，一般情況下有可能出現(xiàn)的就是你的URL中文用的是UTF-8但提交時(shí)可能把它當(dāng)成GBK了，或者是GBK當(dāng)成UTF-8了，這時(shí)候會(huì)有部分不出出現(xiàn)錯(cuò)誤，但有一些會(huì)出現(xiàn)?或方框，這是因?yàn)閁TF-8中的碼表跟GBK的不是一樣的，但有部分一樣。而出現(xiàn)?大多數(shù)情況下是轉(zhuǎn)成ISO-8859-1出問題，出方框是轉(zhuǎn)成GBK出問題，這部分因?yàn)橐f起來會(huì)很麻煩，所以我也沒在這里面提出來，但只要你在所有地方設(shè)置好了編碼，一般就不會(huì)出現(xiàn)這種情況了。

還有你這種情況的出現(xiàn)，有時(shí)是你在TOMCAT里沒設(shè)置好編碼造成的，這個(gè)配置一下就行了的。

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

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

我就是用范型實(shí)現(xiàn)的啊，在05年時(shí)做的一個(gè)項(xiàng)目時(shí)就用上了，當(dāng)時(shí)JDK1.5好像才剛出沒多久。一直沒發(fā)現(xiàn)什么問題

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

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

界面感覺有點(diǎn)MindJet的味道.....不過總體上感覺還不錯(cuò).

@Feng
Mock可以模擬一個(gè)環(huán)境，在重現(xiàn)WEB應(yīng)用中的某些特殊BUG時(shí)很有用。

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

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

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

2、我說的問題之前也說了它的權(quán)限設(shè)置可以看成是“對(duì)餅圖的查看操作，對(duì)曲線圖的查看操作，導(dǎo)出到PDF，也不過就是對(duì)PDF的查看操作”，所以對(duì)于領(lǐng)導(dǎo)的要求也是能完成的，普通管理員只有查看數(shù)據(jù)的權(quán)限，領(lǐng)導(dǎo)有查看餅圖的權(quán)限，查看曲線圖的權(quán)限。

3、當(dāng)然我說的也并非是針對(duì)某一需求的理解，而是將頁面的操作進(jìn)行抽象后的理解所說的。呵呵

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

@江上一葉舟
我是對(duì)你這個(gè)方法而說的：
public static boolean isValidPrivilege(int privilege)//判斷是否具有權(quán)限
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方法要是有任何一個(gè)權(quán)限都會(huì)返回TRUE，但結(jié)果與return privilege >0是一樣的。難道不是？

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

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

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

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

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

根據(jù)beanSoft的　 JSP 中 AJAX 的表單提交中文問題的簡單解決方案 - GBK 版本(原創(chuàng)) http://www.aygfsteel.com/beansoft/archive/2006/12/31/91144.html
果然可以解決，不得不汗一個(gè)，在GBK編碼下，無論如何都不能用SEND方法發(fā)送參數(shù)，而要把參數(shù)加到URL中然后OPEN，不管是GET或POST都這樣，真暈了。
使用encodeURIComponent 后的參數(shù)必須為UTF-8，如果不用的話就是XMLHTTP設(shè)置在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的實(shí)現(xiàn)吧。

要注意的是保存文件時(shí)的編碼也要調(diào)成一致的，要不也會(huì)亂碼。不過ECLIPSE好像有根據(jù)JSP頁面設(shè)置的ENCODING設(shè)置默認(rèn)編碼的智能，一定也就不會(huì)有問題了

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

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

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

客戶欠款表和客戶還款表就是一個(gè)多對(duì)多的關(guān)系，
客戶信息表可以看成是一個(gè)中間表，客戶欠款表和客戶還款表應(yīng)該通過中間表進(jìn)行連接，三表聯(lián)合查詢

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

沒關(guān)系的，寫出來的東西就是要讓大家共同學(xué)習(xí)的，如果不讓轉(zhuǎn)載，那就沒意義了

支持

我也是在困惑著這個(gè)問題，因?yàn)槲覍?duì)很多主面都有興趣，但我知道如果不專一一點(diǎn)是沒多大成就的，現(xiàn)在就在為應(yīng)該專注于哪一方面而煩。（測(cè)試我也是很有興趣的，只是好像很難找到適合的工作）

用過濾器不行嗎？？

沒錯(cuò),要搞定JSP的亂碼問題就得搞懂編碼,當(dāng)時(shí)我和了一個(gè)月的時(shí)間去研究編碼,有些心得.

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

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

其實(shí)兩個(gè)人都沒有錯(cuò),只是大家站的位置不同,看到的東西不同而已.

同情ing,節(jié)衰吧,哈哈.我確實(shí)也看到很多人都說斷線了.國內(nèi)的網(wǎng)絡(luò)整體素質(zhì)還有待提高:)

最近在做一些需求分析和系統(tǒng)分析的工作，也在考慮這個(gè)問題，看完后覺得自己也犯了這“過度設(shè)計(jì)”這個(gè)錯(cuò)。想得太多了，現(xiàn)在一般公司不用WINDOWS的大概沒有那么多個(gè)。

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

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

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


－－－－－－－－－－－－－－－－－－－－－－－－－－－－
最近我的blog地址更改了，超郁悶適應(yīng)新環(huán)境中。。。。。。。。

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

該不會(huì)是真的得獎(jiǎng)了吧？:目

再一次借用泡泡的文章

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

對(duì)了，沒經(jīng)過你同意，我就引用了你的文章，請(qǐng)見諒，不過我有注明出處。^_^，如有不當(dāng)，請(qǐng)告訴我，我馬上刪除。

看過你這篇文章，我決定試試firefox,之前我一直在用IE，不為什么，只因?yàn)樗奖悖挥米约涸侔惭b。