編者按：2008年8月4日，StackOverflow 網友 Bert F 發帖提問：哪本最具影響力的書，是每個程序員都應該讀的？
“如果能時光倒流，回到過去，作為一個開發人員，你可以告訴自己在職業生涯初期應該讀一本， 你會選擇哪本書呢？我希望這個書單列表內容豐富，可以涵蓋很多東西。”
很多程序員響應，他們在推薦時也寫下自己的評語。 以前就有國內網友介紹這個程序員書單，不過都是推薦數 Top 10的書。
其實除了前10本之外，推薦數前30左右的書籍都算經典，筆者整理編譯這個問答貼，同時摘譯部分推薦人的評語。
下面就按照各本書的推薦數排列。
1、《代碼大全》 史蒂夫·邁克康奈爾
推薦數：1684
“優秀的編程實踐的百科全書，《代碼大全》注重個人技術，其中所有東西加起來， 就是我們本能所說的“編寫整潔的代碼”。這本書有50頁在談論代碼布局。” —— Joel Spolsky
對于新手來說，這本書中的觀念有點高階了。到你準備閱讀此書時，你應該已經知道并實踐過書中99%的觀念。– esac
Steve McConnell的原作《代碼大全》(第1版)是公認的關于編程的最佳實踐指南之一， 在過去的十多年間，本書一直在幫助開發人員編寫更好的軟件。
現在，作者將這本經典著作全新演繹，融入了最前沿的實踐技術，加入了上百個嶄新的代碼示例， 充分展示了軟件構建的藝術性和科學性。 McConnell匯集了來自研究機構、學術界以及業界日常實踐的主要知識， 把最高效的技術和最重要的原理交織融會為這本既清晰又實用的指南。
無論您的經驗水平如何，也不管您在怎樣的開發環境中工作，也無論項目是大是小， 本書都將激發您的思維并幫助您構建高品質的代碼。
《代碼大全（第2版）)》做了全面的更新，增加了很多與時俱進的內容，包括對新語言、新的開發過程與方法論的討論等等。
推薦數：1504
對于那些已經學習過編程機制的程序員來說，這是一本卓越的書。 或許他們還是在校生，但對要自己做什么，還感覺不是很安全。
就像草圖和架構之間的差別。雖然你在學校課堂上學到的是畫圖，你也可以畫的很漂亮， 但如果你覺得你不太知道從哪兒下手，如果某人要你獨自畫一個P2P的音樂交換網絡圖，那這本書就適合你了。—— Joel
《程序員修煉之道:從小工到專家》內容簡介：《程序員修煉之道》由一系列獨立的部分組成， 涵蓋的主題從個人責任、職業發展，知道用于使代碼保持靈活、并且易于改編和復用的各種架構技術， 利用許多富有娛樂性的奇聞軼事、有思想性的例子及有趣的類比， 全面闡釋了軟件開發的許多不同方面的最佳實踐和重大陷阱。
無論你是初學者，是有經驗的程序員，還是軟件項目經理，《程序員修煉之道:從小工到專家》都適合你閱讀。
推薦數：916
就個人而言，這本書目前為止對我影響醉倒的一本編程書。
《代碼大全》、《重構》和《設計模式》這些經典書會教給你高效的工作習慣和交易細節。 其他像《人件集》、《計算機編程心理學》和《人月神話》這些書會深入軟件開發的心理層面。 其他書籍則處理算法。這些書都有自己所屬的位置。
然而《計算機程序的構造和解釋》與這些不同。 這是一本會啟發你的書，它會燃起你編寫出色程序的熱情； 它還將教會你認識并欣賞美； 它會讓你有種敬畏，讓你難以抑制地渴望學習更多的東西。
其他書或許會讓你成為一位更出色的程序員，但此書將一定會讓你成為一名程序員。
同時，你將會學到其他東西，函數式編程（第三章）、惰性計算、元編程、虛擬機、解釋器和編譯器。
一些人認為此書不適合新手。 個人認為，雖然我并不完全認同要有一些編程經驗才能讀此書，但我還是一定推薦給初學者。 畢竟這本書是寫給著名的6.001，是麻省理工學院的入門編程課程。 此書或許需要多做努力（尤其你在做練習的時候，你也應當如此），但這個價是對得起這本書的。
推薦數：774
這本書簡潔易讀，會教給你三件事：C 編程語言；如何像程序員一樣思考；底層計算模型。 （這對理解“底層”非常重要）—— Nathan
《C程序設計語言》(第2版新版)講述深入淺出，配合典型例證，通俗易懂，實用性強， 適合作為大專院校計算機專業或非計算機專業的C語言教材，也可以作為從事計算機相關軟硬件開發的技術人員的參考書。
《C程序設計語言》(第2版新版)原著即為C語言的設計者之一Dennis M.Ritchie和著名的計算機科學家Brian W.Kernighan合著的 一本介紹C語言的權威經典著作。 我們現在見到的大量論述C語言程序設計的教材和專著均以此書為藍本。 原著第1版中介紹的C語言成為后來廣泛使用的C語言版本——標準C的基礎。
人們熟知的“hello,world”程序就是由本書首次引入的，現在，這一程序已經成為所有程序設計語言入門的第一課。
推薦數：671
《代碼大全》教你如何正確編程； 《人月神話》教你如何正確管理； 《設計模式》教你如何正確設計……
在我看來，代碼只是一個工具，并非精髓。 開發軟件的主要部分是創建新算法或重新實現現有算法。 其他部分則像重新組裝樂高磚塊或創建“管理”層。
我依然夢想這樣的工作，我的大部分時間（>50%）是在寫算法，其他“管理”細節則留給其他人…… —— Ran Biron
- 經典的算法書,被亞馬遜網，《程序員》等評選為2006年最受讀者喜愛的十大IT圖書之一。
- 算法領域的標準教材，全球多所知名大學選用
- MIT名師聯手鑄就，被譽為“計算機算法的圣經”
- 編寫上采用了“五個一”，即一章介紹一個算法、一種設計技術、一個應用領域和一個相關話題。
推薦數：617
《重構:改善既有代碼的設計》清晰地揭示了重構的過程，解釋了重構的原理和最佳實踐方式， 并給出了何時以及何地應該開始挖掘代碼以求改善。 書中給出了70多個可行的重構，每個重構都介紹了一種經過驗證的代碼變換手法的動機和技術。
《重構:改善既有代碼的設計》提出的重構準則將幫助你一次一小步地修改你的代碼，從而減少了開發過程中的風險。
《重構:改善既有代碼的設計》適合軟件開發人員、項目管理人員等閱讀， 也可作為高等院校計算機及相關專業師生的參考讀物。
我想我不得不推薦《重構》：改進現有代碼的設計。—— Martin
我必須承認，我最喜歡的編程語錄是出自這本書：任何一個傻瓜都能寫出計算機能理解的程序， 而優秀的程序員卻能寫出別人能讀得懂的程序。—— Martin Fowler
推薦數：617
自1995年出版以來，本書一直名列Amazon和各大書店銷售榜前列。 近10年后，本書仍是Addison-Wesley公司2003年最暢銷的圖書之一。 中文版銷售逾4萬冊。
就我而言，我認為四人幫編著的《設計模式》是一本極為有用的書。 雖然此書并不像其他建議一樣有關“元”編程，但它強調封裝諸如模式一類的優秀編程技術， 因而鼓勵其他人提出新模式和反模式（antipatterns），并運用于編程對話中。—— Chris Jester-Young
推薦數：588
在軟件領域，很少能有像《人月神話》一樣具有深遠影響力并且暢銷不衰的著作。
Brooks博士為人們管理復雜項目提供了最具洞察力的見解。 既有很多發人深省的觀點，又有大量軟件工程的實踐。 本書內容來自Brooks博士在IBM公司System/360家族和OS/360中的項目管理經驗。
該書英文原版一經面世，即引起業內人士的強烈反響，后又譯為德、法、日、俄中等多種語言，全球銷量數百萬冊。 確立了其在行業內的經典地位。
推薦數：542
《計算機程序設計藝術》系列著作對計算機領域產生了深遠的影響。 這一系列堪稱一項浩大的工程，自1962年開始編寫，計劃出版7卷，目前已經出版了4卷。
《美國科學家》雜志曾將這套書與愛因斯坦的《相對論》等書并列稱為20世紀最重要的12本物理學著作。 目前Knuth正將畢生精力投入到這部史詩性著作的撰寫中。
這是高德納傾注心血寫的一本書。—— Peter Coulton
10、《編譯原理》（龍書）
推薦數：462
我很奇怪，居然沒人提到龍書。（或許已有推薦，我沒有看到）。 我從沒忘過此書的第一版封面。 此書讓我知道了編譯器是多么地神奇絕妙。- DB
推薦數：445
強大的寫作陣容。
- 《Head First設計模式》(中文版) 作者Eric Freeman；
- ElElisabeth Freeman是作家、講師和技術顧問。
- Eric擁有耶魯大學的計算機科學博士學位，E1isabath擁有耶魯大學的計算機科學碩士學位。
- Kathy Sierra(javaranch．com的創始人)FHBert Bates是暢銷的HeadFirst系列書籍的創立者，也是Sun公司Java開發員認證考試的開發者。
本書的產品設計應用神經生物學、認知科學，以及學習理論，這使得這本書能夠將這些知識深深地印在你的腦海里， 不容易被遺忘。
本書的編寫方式采用引導式教學，不直接告訴你該怎么做，而是利用故事當作引子，帶領讀者思考并想辦法解決問題。 解決問題的過程中又會產生一些新的問題，再繼續思考、繼續解決問題，這樣可以加深體會。
作者以大量的生活化故事當背景，例如第1章是鴨子，第2章是氣象站，第3章是咖啡店， 書中搭配大量的插圖(幾乎每一頁都有圖)，所以閱讀起來生動有趣，不會感覺到昏昏欲睡。
作者還利用歪歪斜斜的手寫字體，增加“現場感”。 精心設計許多爆笑的對白，讓學習過程不會太枯燥。 還有模式告白節目，將設計模式擬人化成節目來賓，暢談其內在的一切。 每一章都有數目不等的測驗題。 每章最后有一頁要點整理，這也是精華所在，我都是利用這一頁做復習。
我知道四人幫的《設計模式》是一本標準書，但倒不如先看看這部大部頭，此書更為簡易。 一旦你了解了解了基本原則，可以去看四人幫的那本圣經了。- Calanus
推薦數：437
如果下昂真正深入閱讀，我推薦道格拉斯·侯世達（Douglas Hofstadter）的《哥德爾、艾舍爾、巴赫書》。 他極為深入研究了程序員每日都要面對的問題：遞歸、驗證、證明和布爾代數。 這是一本很出色的讀物，難度不大，偶爾有挑戰，一旦你要鏖戰到底，將是非常值得的。 – Jonik
推薦數：329
細節之中自有天地，整潔成就卓越代碼
盡管糟糕的代碼也能運行，但如果代碼不整潔，會使整個開發團隊泥足深陷， 寫得不好的代碼每年都要耗費難以計數的時間和資源。 然而這種情況并非無法避免。
著名軟件專家RoberfC.Marlin在《代碼整潔之道》中為你呈現出了革命性的視野。 Martin攜同ObjectMetltor公司的同事，從他們有關整潔代碼的最佳敏捷實踐中提煉出軟件技藝的價值觀， 以饗讀者，讓你成為更優秀的程序員——只要你著手研讀《代碼整潔之道》。
閱讀《代碼整潔之道》需要你做些什么呢？你將閱讀代碼——大量代碼。 《代碼整潔之道》促使你思考代碼中何謂正確，何謂錯誤。 更重要的是，《代碼整潔之道》將促使你重新評估自己的專業價值觀，以及對自己技藝的承諾。
從《代碼整潔之道》中可以學到：
- 好代碼和糟糕的代碼之間的區別；
- 如何編寫好代碼，如何將糟糕的代碼轉化為好代碼；
- 如何創建好名稱、好函數、好對象和好類；
- 如何格式化代碼以實現其可讀性的最大化；
- 如何在不妨礙代碼邏輯的前提下充分實現錯誤處理；
- 如何進行單元測試和測試驅動開發。
雖然《代碼整潔之道》和《代碼大全》有很多共同之處，但它有更為簡潔更為實際的清晰例子。 – Craig P. Motlin
推薦數：297
在我職業生涯早期，Scott Meyer的《Effective C++》和后續的《More Effective C++》都對我的編程能力有著直接影響。 正如當時的一位朋友所說，這些書縮短你培養編程技能的過程，而其他人可能要花費數年。
去年對我影響最大的一本書是《大教堂與市集》，該書教會我很有關開源開發過程如何運作，和如何處理我代碼中的Bug。 – John Channing
推薦數：282
多年以來，當程序員們推選出最心愛的計算機圖書時，《編程珠璣》總是位列前列。 正如自然界里珍珠出自細沙對牡蠣的磨礪，計算機科學大師Jon Bentley以其獨有的洞察力和創造力， 從磨礪程序員的實際問題中凝結出一篇篇不朽的編程“珠璣”， 成為世界計算機界名刊《ACM通訊》歷史上最受歡迎的專欄， 最終結集為兩部不朽的計算機科學經典名著，影響和激勵著一代又一代程序員和計算機科學工作者。
本書為第一卷，主要討論計算機科學中最本質的問題：如何正確選擇和高效地實現算法。
盡管我不得不羞愧地承認，書中一半的東西我都沒有理解，但我真的推薦《編程珠璣》，書中有些令人驚奇的東西。 – Matt Warren
16、《修改代碼的藝術》by Michael Feathers
本書是繼《重構》和《重構與模式》之后探討修改代碼技術的又一里程碑式的著作， 而且從涵蓋面和深度上都超過了前兩部經典。 書中不僅講述面向對象語言（Java、C#和C++）代碼，也有專章討論C這樣的過程式語言。
作者將理解、測試和修改代碼的原理、技術和最新工具（自動化重構工具、單元測試框架、仿對象、集成測試框架等）， 與解依賴技術和大量開發和設計優秀代碼的原則、最佳實踐相結合，許多內容非常深入，而且常常發前人所未發。
書中處處體現出作者獨到的洞察力，以及多年開發和指導軟件項目所積累的豐富經驗和深厚功力。 通過這部集大成之作，你不僅能掌握最頂尖的修改代碼技術，還可以大大提高對代碼和軟件開發的領悟力。
我認為沒有任何一本書能向這本書一樣影響了我的編程觀點。 它明確地告訴你如何處理其他人的代碼，含蓄地教會你避免哪些（以及為什么要避免）。- Wolfbyte
同意。很多開發人員討論用干凈的石板來編寫軟件。 但我想幾乎所有開發人員的某些時候是在吃其他開發人員的狗食。– Bernard Dy
這是一本講述計算機工作原理的書。
不過，你千萬不要因為“工作原理”之類的字眼就武斷地認為，它是晦澀而難懂的。 作者用豐富的想象和清晰的筆墨將看似繁雜的理論闡述得通俗易懂，你絲毫不會感到枯燥和生硬。 更重要的是，你會因此而獲得對計算機工作原理較深刻的理解。 這種理解不是抽象層面上的，而是具有一定深度的，這種深度甚至不遜于“電氣工程師”和“程序員”的理解。
不管你是計算機高手，還是對這個神奇的機器充滿敬畏之心的菜鳥， 都不妨翻閱一下《編碼:隱匿在計算機軟硬件背后的語言》，讀一讀大師的經典作品，必然會有收獲。
我推薦Charles Petzold的《編碼》。 在這個充滿工具和IDE的年代，很多復雜度已經從程序員那“抽取”走了，這本書一本開眼之作。 – hemil
對我影響最大的那本書是 Robert Pirsig 的《禪與摩托車維修藝術》。 不管你做什么事，總是要力求完美，徹底了解你手中的工具和任務，更為重要的是， 要有樂趣（因為如果你做事有樂趣，一切將自發引向更好的結果）。 – akr
Demarco 和 Lister 表明，軟件開發中的首要問題是人，并非技術。 他們的答案并不簡單，只是令人難以置信的成功。 第二版新增加了八章內容。 – Eduardo Molteni
這是一本訪談筆錄，記錄了當今最具個人魅力的15位軟件先驅的編程生涯。 包括DonaldKnuth、Jamie Zawinski、Joshua Bloch、Ken Thompson等在內的業界傳奇人物，為我們講述了 他們是怎么學習編程的，在編程過程中發現了什么以及他們對未來的看法， 并對諸如應該如何設計軟件等長久以來一直困擾很多程序員的問題談了自己的觀點。
一本非常有影響力的書，可以從中學到一些業界頂級人士的經驗，了解他們如何思考并工作。 – Jahanzeb Farooq
21、《Surely You’re Joking, Mr. Feynman! / 別鬧了，費曼先生！》
雖然這本書可能有點偏題，但不管你信不信，這本書曾在計算機科學專業課程的閱讀列表之上。 一個優秀的角色模型，一本有關好奇心的優秀書籍。 – mike511
此書第二版教你如何編寫漂亮并高效的代碼，雖然這是一本Java書，但其中有很多跨語言的理念。 – Marcio Aguiar
很奇怪，還沒人推薦 Martin Fowler 的《企業應用架構模式》- levi rosol
24、《The Little Schemer》和《The Seasoned Schemer》 nmiranda
這兩本是LISP的英文書，尚無中文版。 美國東北大學網站上也有電子版。
25、《交互設計之路》英文名：《The Inmates Are Running The Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity》該書作者：Alan Cooper，人稱Visual Basic之父，交互設計之父。
本書是基于眾多商務案例，講述如何創建更好的、高客戶忠誠度的軟件產品和基于軟件的高科技產品的書。 本書列舉了很多真實可信的實際例子，說明目前在軟件產品和基于軟件的高科技產品中，普遍存在著“難用”的問題。
作者認為，“難用”問題是由這些產品中存在著的高度“認知摩擦”引起的， 而產生這個問題的根源在于現今軟件開發過程中欠缺了一個為用戶利益著想的前期“交互設計”階段。 “難用”的產品不僅損害了用戶的利益，最終也將導致企業的失敗。
本書通過一些生動的實例，讓人信服地講述了由作者倡導的“目標導向”交互設計方法在解決“難用”問題方面的有效性， 證實了只有改變現有觀念，才能有效地在開發過程中引入交互設計，將產品的設計引向成功。
本書雖然是一本面向商務人員而編寫的書，但也適合于所有參與軟件產品和基于軟件的高科技產品開發的專業人士， 以及關心軟件行業和高科技行業現狀與發展的人士閱讀。
他還有另一本中文版著作：《About Face 3 交互設計精髓》
26、《Why’s (Poignant) Guide to Ruby 》
如果你不是程序員，閱讀此書可能會很有趣，但如果你已經是個程序員，可能會有點乏味。
27、《Unix編程藝術》
It is useful regardless operating system you use. – J.F. Sebastian
不管你使用什么操作系統，這本書都很有用。 – J.F. Sebastian
45個習慣，分為7個方面：工作態度、學習、軟件交付、反饋、編碼、調試和協作。
每一個具體的習慣里，一開始提出一個謬論，然后展開分析，之后有正隊性地提出正確的做法，并設身處地地講出了正確做法給你個人的“切身感受”，最后列出幾條注意事項，幫助你修正自己的做法（“平衡的藝術”）。
前面已經提到的很多書都啟發了我，并影響了我，但這本書每位程序員都應該讀。 它向我展示了單元測試和TDD的重要性，并讓我很快上手。 – Curro
我不關心你的代碼有多好或優雅。 如果你沒有測試，你或許就如同沒有編寫代碼。 這本書得到的推薦數應該更高些。 人們討論編寫用戶喜歡的軟件，或既設計出色并健壯的高效代碼，但如果你的軟件有一堆bug，談論那些東西毫無意義。– Adam Gent
可用性設計是Web設計中最重要也是難度最大的一項任務。 《點石成金－訪客至上的網頁設計秘笈（原書第二版）》作者根據多年從業的經驗，剖析用戶的心理， 在用戶使用的模式、為掃描進行設計、導航設計、主頁布局、可用性測試等方面提出了許多獨特的觀點， 并給出了大量簡單、易行的可用性設計的建議。
本書短小精煉，語言輕松詼諧，書中穿插大量色彩豐富的屏幕截圖、趣味叢生的卡通插圖以及包含大量信息的圖表， 使枯燥的設計原理變得平易近人。
本書適合從事Web設計和Web開發的技術人員閱讀，特別適合為如何留住訪問者而苦惱的網站/網頁設計人員閱讀。 這是一本關于Web設計原則而不是Web設計技術的書。
本書作者是Web設計專家，具有豐富的實踐經驗。 他用幽默的語言為你揭示Web設計中重要但卻容易被忽視的問題，只需幾個小時， 你便能對照書中講授的設計原則找到網站設計的癥結所在，令你的網站煥然一新。
取決于你所追求的目標。 我喜歡《代碼大全》是因純編程，《點石成金》是一本有關UI設計的卓越書籍。 – Justin Standard
posted @
2012-08-14 17:46 justjavac(迷渡) 閱讀(206) |
評論 (0) |
編輯 收藏
php新手開發的作品通常都有以下不足：
1、網站目錄不合理，無法分辨各個功能的文件夾及文件，沒有系統內核。
2、網站未經過初始化，沒有安全過濾，沒有統一入口。
3、基本沒有class，甚至連function都很難找到，冗余代碼多，并有大量的重復文件。
4、PHP代碼混編，非MVC模式。
發現了自己的不足，就要針對不足之處加強技術學習，多從成熟的系統作品中學習，
先解決以上幾個方面的問題，再多了解最新的php安全漏洞，以及編程技巧，你就會
逐漸成為開發高手！
最后一點，php上手雖快，但沒有系統學習過軟件專業的課程和知識是肯定不夠的，
無 論你是哪一種語言和工具的開發者，算法設計與分析是你一定要精通的，認真
扎實地學過數據結構、算法、編繹原理這些專業課程后，你會發現：
你 不論學什么開發，都會感到的自己的悟性非凡！
posted @
2010-07-02 11:54 justjavac(迷渡) 閱讀(150) |
評論 (0) |
編輯 收藏 1. CI中的controller都應當小寫。剛開始為了區分單詞，把第二個單詞大寫了，結果就是不認default_controller。事實證明這是錯誤的。放到linux下面就不靈了，應該全部小寫，如果你大寫了，CI會認為這是libraries里面的東西。不管怎樣都應該全部小寫，至少可以避免linux下區分大小寫的問題。
2. 分頁的問題。CI的官方論壇下提供了一些源代碼，怎樣寫分頁函數我就不多說了，可以直接看高手的。關鍵是傳遞頁面參數的時候，不要忘了修改segment。一開始怎么傳都不對，后來才想起來我的網址已經是localhost/codeigniter/aaa/bbb/3/10了，這樣segment也要相應改變。分頁參數在第幾個/后，他就是uri->segment(幾)。如果是搜索之后的分頁，那么$config['total_rows']就不是count_all了，而是加入where之后的query的記錄數。想起來倒是有一個問題還沒解決，就是在你點search之后，一般需要用JS把網址轉換成CI固有的模式，但是怎樣使這個js生成的網址包含到site_url中，我沒有解決，只能手工了（仔細想想還是挺簡單的呵呵，自己造網址不用site_url）。
3. MVC模式我已經比較適應了。將頁面都放在view中，控制語句放在controller中，而函數放在model中。剛開始有很多人和我一樣想要在view或者control中加一些語句，只能說，不行，也不規范。最好的辦法是寫成helper，如果是數據庫的二次調用的話，可以用inner join合并。
4. htaccess的問題。很多人肯定和我一樣，一開始接觸的時候就是感興趣怎樣可以去掉index.php。雖然網上已經泛濫了，但是我再寫一次吧。其實就兩個工作，第一，在根目錄寫一個.htaccess的文檔，第二，開啟apache中的rewrite模塊。
1）htaccess的寫法很多。這是基于你對CI各層目錄的安排決定的。我的安排：除了application中的內容外。將其他所有東西放在根目錄下的www目錄下，其中圖片放在www/images/下，flash放在www/flash/下，xml放在www/xml下，js放在www/js下。。。?？傊言趙ww里面。所有views在title下面加上<base href="<?=base_url()?>" />這句話，系統就能識別你的根目錄了，所有鏈接改成site_url()就可以保證路徑不會出錯了。于是，我的htaccess是這樣的：
RewriteEngine on
RewriteCond $1 !^(index\.php|www|uploadfiles|robots\.txt)
RewriteRule ^(.*)$ /index.php/$1 [L] [L]
第一行是將rewrite打開，第二行是不rewrite的例外，包括index.php本身，www目錄，uploadfiles（這個參見5），還有robots搜索，第三行自然就是將index.php隱藏的rewrite規則了，即剩下的網址由于原來都是localhost/codeigniter/index.php/aaa/bbb的模式，現在可以去掉index.php了。而www下的網址不涉及index.php，用不到這個規則，所以要排除。
2）首先找到apache下面的http.conf，路徑是apache的conf目錄下。找到這一行：LoadModule rewrite_module modules/mod_rewrite.so，將前面的#去掉，也就是說開啟這個module。另外需要找到rewrite的目錄行，將AllowOverride設置為All，其實就是roadmodule下面的那個directory.
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# Options FileInfo AuthConfig Limit
#
AllowOverride All
3）在CI的config目錄下的config.php中，將$config['index_page'] = "index.php"改為$config['index_page'] = “”，這樣就大功告成啦?。〔挥幂斎雐ndex.php也可以訪問了。其實更關鍵的是你的各個目錄的路徑安排。
5.FCKEditor的問題。應該說我在應用的時候沒有遇到任何麻煩，除了上傳時候的路徑讓我一頓好找。我覺得設置成根目錄下的/uploadfiles是不錯的選擇，當然別忘了在htaccess中把uploadfiles也放在不rewrite的隊伍中。因為我現在的習慣是所有的文件編碼都設置成utf-8，所以網上經常說的亂碼的現象沒有遇到。
基本上就是這些基本的問題了，我做的其實就是簡單的企業網站，沒有高級應用，所以也沒有遇到更復雜的問題。等考完GT可以嘗試做一個更復雜的網站，和AJAX結合后再寫一些心得。下次要再做這樣的CMS，后臺直接搞定，省了不少時間。而且對于我這樣的PHP爛人來說，CI幫我解決了很多安全問題，同時也提高了效率。
有點過度興奮了，寫得超級亂，我自己都不愿意回過頭去細細檢查了，具體問題可以再聯系我，只要我能解答。最后上傳一個驗證碼的helper吧，版權歸CI論壇上的同學所有，我只是轉一下，順便寫一下用法。。。
點擊下載此文件
1）首先在controller中引用getcode_helper.php， $this->load->helper('getcode');
建立一個function比如
- function createcode()
- {
- code();
- }
2）驗證碼圖片鏈接地址：<img id="codeimage" src="<?=site_url('controller路徑/createcode')?>
3）表單提交時驗證函數：
- function seccode_check($str)
- {
- if(chk_code($str))
- {
- return TRUE;
- }
- else
- {
- return FALSE;
- }
- }
posted @
2010-07-02 11:53 justjavac(迷渡) 閱讀(231) |
評論 (0) |
編輯 收藏在與許多客戶的接觸中，我發現有必要建立一套SOA的基本原則。下面的部分將介紹SOA中應有的基本原則。這些并非絕對真理，它們更像一個用于SOA相關討論的參考框架。你會發現：前四項衍生自Don Box提出的四項原則，盡管隨著時間的流逝，這四項原則的描述可能已經有了些變化。
相關廠商內容
1. 明確邊界:服務被調用時，與實現其功能相關的內容都應被傳遞過來。對服務的所有訪問都應該通過公共接口進行。調用服務時，非隱含的假設是必須的。“服務與消息緊密聯系，因為參數進出服務的唯一方式是通過消息進行的”。作為通用的模式，服務調用不應依賴于共享的上下文，而應被作為無狀態的模塊。契約描述了服務的功能性與非功能性的能力和特點，管理著服務提供的接口。服務調用是一個具有業務邏輯效果的行為，可能有大量的資源開銷，并且導致一系列不同于本地方法調用和遠程過程調用的錯誤。服務的調用絕非遠程過程調用。
服務的使用和提供應該盡可能地簡單，因此與服務間的交互沒必要被隱藏得太多。在SOA中，服務發送和接收的消息、服務契約以及服務本身都應當是最好的構件。這就意味著，例如，被用到的編程模型和工具至少應該提供一個API，這個API會幫助服務的編程人員了解上述概念。總的來說，一個明確的接口會封裝服務的內在實現，而服務通過該接口發布自己的功能；與服務交互是一個具體的行為，它依賴于服務使用者和提供者之間消息的傳遞。
2. 共享契約和架構，而不是類:基于一份服務描述（一份契約），服務使用者和服務提供者都可以獲得使用或提供服務的全部所需。根據松耦合原則，服務提供者不能依靠服務使用者來重用那些依賴于使用者環境的代碼。畢竟，服務使用者可能使用不同的開發環境和運行環境。這條原則給SOA體系中所能交換的數據加上了嚴格的限制。理想的情況是，數據以符合一種或多種模式的XML文檔形式被交換，因為這種方式可應用于任何你能想到的編程環境。因此，因為這條原則在基于DCOM和基于RMI的環境中是不可能被遵守的，所以這兩種環境基本上無法成為SOA的可用選項。
3. 策略驅動:為了與服務交互，必須滿足以下兩組不同的要求：
- 提供者提供的功能、語法和語義必須適應使用者的需求；
- 技術能力與需要必須匹配。
例如，一個服務提供者提供了能夠精確滿足用戶需求的服務，但該服務是基于JMS的，可使用者只能使用HTTP方式（比如，服務被應用于.NET平臺）。服務提供者可能要求消息級別的加密采用XML加密標準，而使用者只支持采用SSL技術來保障傳輸層上的安全。即使在那些交互雙方都擁有足夠能力的案例中，它們的這些能力仍舊需要被“啟用”。例如，
提供者可能根據不同的使用者需求，對響應的消息使用不同的算法進行加密。 為了使盡可能多的形形色色的使用者能對服務進行訪問，一種策略機制已經被作為SOA工具集的一部分引入了。在服務接口對功能進行描述的同時，策略對不同的，非功能性的能力和需求進行了指定。（譯者注：
策略指定的是服務之外的補充信息，是對服務使用者提出的特征要求）。
4. 自治：與明確邊界原則相關，服務自治意味著，接口成為服務與外界聯系的唯一方式，至少從SOA的角度來看是這樣的。需要注意的是，服務的運行環境一定是可變的。例如，在絲毫不影響使用者的情況下，就可以從輕量級的原型實現轉換到成熟的、基于應用服務器的協同組件集。
服務能夠被彼此獨立的修改、部署、發布新版本和管理。服務提供者不能寄希望于服務使用者，期望它們依靠自己的能力迅速適應新版本的服務，有的使用者可能甚至沒這個能力或者根本不愿去適應新版本的服務接口（尤其是當這些服務接口超出了服務提供者控制范圍的時候）。
5. 采用可傳輸的協議格式，而非API：服務通常采用協議格式來發布，協議格式應該是明確的、可傳輸的并且被服務所支持的。這一點與前兩條原則非常相關，但卻帶來了新的見解：為保證一個服務最大程度的可訪問性（及長期的可用性），只要交互過程遵守為該服務定義的策略，那么由任何依照服務接口進行消息交換的平臺都可以訪問該服務。例如，通過以這一原則來測試主流的動態編程語言（如Perl、Python或Ruby），我們可以去考慮該語言能否使用或提供一個特定的服務。雖然，在現有的技術實現里，這條原則可能還沒有發揮作用，但這個思路可以作為下列準則的試金石：
- 使用開放的標準或者可閱讀的描述來描述所有消息格式。
- 不需要特定的資源就可以創造出符合這些合理的模式的消息。
- 成功通信所必需的附加信息，例如包含安全性或可靠性約束的頭信息，它們的語義和語法要遵循公開的規范和標準。
- 服務交互時所使用的傳輸（或傳遞）協議中至少有一個是標準的網絡協議，或它可以通過標準的網絡協議來訪問。
6. 面向文檔：服務交互時，數據是以文檔的形式來傳遞的。
文檔是一個被明確模塊化的，有層次結構的數據容器。面向文檔的一個重要特征就是自描述。最理想的情況下，文檔是對現實世界中的文件（如訂單、發票或帳單）的建模。文檔應該被設計來確保它在問題域的上下文中發揮作用，這意味著它們可能應用于一個或更多的服務。
與現實世界的紙制文檔相似，和服務交換信息的文檔將包含冗余的信息。例如，
文檔中可能同時包含了客戶ID和客戶地址信息（盡管客戶ID可能已經足夠了）。這種冗余是可以接受的，因為它將服務使用者和提供者雙方的服務接口和隱含數據模型隔離開來。應用面向文檔的模式的同時，服務調用成為有意義的業務邏輯消息的交換，而非上下文無關的RPC調用。雖然通常可以認為XML將被作為服務文檔的格式和語法，但它還沒有成為標準。
在一個SOA連接中，參與者之間的消息流轉于不同的系統，使得各個系統之間彼此獨立。松耦合原則要求參與者對共知的依賴越少越好。當消息在分布式對象或RPC基礎架構中發送時，客戶端和服務器端使用由同一個接口描述文檔生成的代理類(stub和skeleton）。如果不是這種情況的話，當契約不支持雙方的交互時，通訊就會停止。因為這個原因，RPC風格的基礎架構要求客戶端和服務器端程序代碼的同步運行。
7. 松耦合：多數SOA的倡導者都認為松耦合是一個很重要的概念。不幸的是，對于究竟哪些特征造成一個系統松耦合，有許多不同的看法。一個系統可以在多個維度表現為松耦合或緊耦合，它依賴于具體的要求和上下文，系統可能會在一些維度是松耦合的，在另一些維度是緊耦合的。這些維度包括：
- 時間：當參與者在時間上是松耦合時，它們不需要在同一時間啟動并進行通訊。這要求兩者之間采用某種緩沖或隊列機制，盡管這種機制與松耦合無關。當參與的一方向另一方發送消息時，交互的繼續不依賴于邏輯上或物理上能否立即返回應答消息。
- 位置：如果一方參與者查詢與之通信的另一方參與者的地址，另一方的地址可以透明地進行變更，不需要重新編程、重新配置或者甚至不需要通信伙伴的重新啟動。這意味著查找（lookup）過程采用某種目錄或地址來存儲服務終端的地址。（對應SOA提供的目錄服務）
- 類型：同靜態與動態，弱類型與強類型這些編程的概念類似，參與者既可以全部依賴也可以部分依賴文檔結構來實現它的功能。
- 版本：參與者可以依賴服務接口的特定版本，也可以兼容某個范圍內的版本。所需匹配的版本越確切，參與者在這個方面上的松耦合性就越差。一個好的原則是遵循Postel法則（譯者注：Postel’s Law——“Be liberal in what you accept, and conservative in what you send.”）：服務提供者應盡可能兼容許多不同的版本，這將使它更加健壯（可能甚至需要容錯），服務使用者應盡可能遵循精確的語法和文檔類型。這將增加整個系統的穩定性和靈活性。
- 基數：服務消費者和提供者可能是1對1的關系，尤其是在請求或響應交互發生時，或隊列被明確使用的情況下。在別的情況下，服務使用者（在這種情況下，稱作“消息發送者”或“事件源”更為合理）可能既不知道也不關心有多少人接受了消息。
- 查找（Lookup）：參與者打算調用服務時，既可以依賴服務提供者的物理名或邏輯名，也可以先通過一組功能描述來執行查找（lookup）操作。這意味著存在一個注冊表和（或）倉庫，對存儲其中的使用者需求和提供者能力進行直接或間接的匹配。
- 接口：參與者可能要綁定到一個特定的服務接口或是支持一個通用的接口。如果使用通用接口，所有該接口的使用者都能與所有該接口的提供者進行交互。盡管可能乍看起來這有些笨拙，但單一通用（統一）接口的原則就是WWW架構的核心。
創造一個滿足以上所有維度的松耦合系統，既不可行，也沒必要。不同類型的服務要做不同的取舍。Carlos Perez的經典之作中(如這里和這里)有更多的關于松耦合各個維度的討論。
8. 遵循標準:一個SOA應用中應遵循的一個關鍵原則是，
信賴標準而非專有的API和格式。標準存在于技術方面，如數據格式、元數據、傳輸協議；也存在于業務層面，如文檔的類型。（例如，UBL中所提到的那些）（譯者注：UBL定義了業務文檔的通用XML庫，UBL的文檔類型包括訂單、發票等）
很顯然，一些人認為專有的解決方案，如一些EAI或消息服務提供商提供的方案，都遵循SOA原則。這個原則不遺余力地強調標準的重要性。當然，由于有太多可供選擇的標準，什么情況用何種標準成了頗具爭議的問題。標準的一個重要方面是它的可接受性（在Web服務的標準中，基本上可以認為“Microsoft肯定要插上一腳”）。
9. 獨立于軟件供應商:任何架構性的原則都不應依賴特定供應商的產品。將抽象的概念轉化為具體的，可運行的系統的過程中，不可避免的要決定使用何種具體的產品，包括商業的或者免費開源的軟件。這些決定都不應影響架構層。這就意味著要盡可能的依賴互操作性和可移植性的標準。因此，要應用支持適當標準的技術來構建服務提供者和使用者，不要受限于任何軟件供應商的技術路線。
10. 元數據驅動:SOA中所有的元數據對象都需要被按照一種方式儲存起來，這種方式將確保元數據對象能夠在設計和運行時被發現、檢索和解釋。
元數據對象包括對服務接口、參與者、端點和綁定信息、組織單元和職責、文檔類型或模式、使用者或提供者關系等的描述。這些對象的用途應當是被代碼自動生成或者解釋，成為服務和參與者生命周期的一部分。
以上是我的原則列表。 即使你不完全同意——而坦率地講，我也不希望你完全同意， 至少不是全部都同意——我希望你能帶著它們來引發一些討論!
posted @
2010-07-02 11:53 justjavac(迷渡) 閱讀(185) |
評論 (0) |
編輯 收藏引領科技為您講解配置 codeigniter，codeigniter 基本配置信息在 application/config/config.php 文件，本文詳細講解每一個基本配置選項，從而快速掌握 codeigniter 進行開發。
$config['base_url'] = "http://www.example.com/"
您網站的網址，codeigniter 會根據這個網址來生成鏈接、表單地址等。
$config['index_page'] = "index.php"
codeigniter 根目錄下的 index.php 文件名，codeigniter 會使用它來生成鏈接地址。如果使用隱藏 index.php 的 URL，將其設置為空字符串：$config['index_page'] = ""。
$config['uri_protocol'] = "AUTO"
codeigniter 生成 URL 使用的格式，設置為“AUTO”自動探測。如果鏈接不能正常工作，可以嘗試以下值：
PATH_INFO、QUERY_STRING、REQUEST_URI、ORIG_PATH_INFO。
$config['url_suffix'] = ""
codeigniter 產生鏈接時使用的 URL 后綴，如果要實現偽靜態，可以設置 $config['url_suffix'] = ".html"。
$config['language'] = "english"
codeigniter 程序默認使用的語言
$config['charset'] = "UTF-8"
codeigniter 程序默認使用的字符集
$config['enable_hooks'] = FALSE
是否啟用鉤子，鉤子功能使得您可以在不修改系統核心文件的基礎上來改變或增加系統的核心運行功能。
$config['subclass_prefix'] = 'MY_'
設置擴展 codeigniter 類庫時使用的類名前綴
$config['permitted_uri_chars'] = 'a-z 0-9~%.:_\-'
設置 codeigniter URL 中允許使用的字符，這是一個正則表達式。當訪問者試圖訪問的 codeigniter URL 包含其它字符時，會得到一個警告。應該盡量限制 codeigniter URL 使用的字符來提高安全性，可以有效的過濾注入攻擊。如果設置為空，允許使用所有字符，強烈建議不要這么做。
$config['enable_query_strings'] = FALSE
codeigniter URL 默認使用分段的 URL，此選項也允許 codeigniter 開啟查詢字符串形式 URL。您可以使用查詢字符串來傳遞要訪問的控制器和函數。例如： index.php?c=controller&m=method。codeigniter 默認使用分段的 URL，查詢字符串的 URL 很多特性不被支持。
$config['controller_trigger'] = 'c'
codeigniter 將查詢字符串中此選項對應的值當做 codeigniter 控制器的名字。
$config['function_trigger'] = 'm'
codeigniter 將查詢字符串中此選項對應的值當做 codeigniter 控制器方法的名字
$config['log_threshold'] = 0
啟用錯誤日志，設置記錄哪些類型的錯誤。
0 = 關閉錯誤日志記錄
1 = 記錄錯誤信息
2 = 記錄調試信息
3 = 記錄通知信息
4 = 記錄所有信息
$config['log_path'] = ''
如果您不想使用默認的錯誤日志記錄目錄配置（system/logs/），可以設置完整的服務器目錄。
$config['log_date_format'] = 'Y-m-d H:i:s'
codeigniter 錯誤日志時間格式
$config['cache_path'] = ''
如果您不想使用默認的緩存目錄（system/cache/）來存儲緩存，可以設置完整的服務器目錄
$config['encryption_key'] = ""
codeigniter 使用的密鑰
$config['global_xss_filtering'] = FALSE
是否對輸入數據（GET、POST）自動過濾跨腳本攻擊
$config['compress_output'] = FALSE
啟用Gzip壓縮達到最快的頁面加載速度
$config['time_reference'] = 'local'
設置時間格式："local"、"GMT"
$config['rewrite_short_tags'] = FALSE
如果您想要使用短標記，但 PHP 服務器不支持，codeigniter 可以通過重寫短標記來支持這一功能。
$config['proxy_ips'] = ''
如果訪問者通過代理服務器來訪問您的網站，您必須設置代理服務器 IP 列表，以識別出訪問者真正的 IP
posted @
2010-07-02 11:49 justjavac(迷渡) 閱讀(1334) |
評論 (0) |
編輯 收藏 EL表達式
1、EL簡介
1）語法結構
${expression}
2）[]與.運算符
EL 提供.和[]兩種運算符來存取數據。
當要存取的屬性名稱中包含一些特殊字符，如.或?等并非字母或數字的符號，就一定要使用 []。
例如：
${user.My-Name}應當改為${user["My-Name"] }
如果要動態取值時，就可以用[]來做，而.無法做到動態取值。例如：
${sessionScope.user[data]}中data 是一個變量
3）變量
EL存取變量數據的方法很簡單，例如：${username}。它的意思是取出某一范圍中名稱為
username的變量。
因為我們并沒有指定哪一個范圍的username，所以它會依序從Page、Request、Session、
Application范圍查找。
假如途中找到username，就直接回傳，不再繼續找下去，但是假如全部的范圍都沒有找到時，
就回傳null。
屬性范圍在EL中的名稱
Page PageScope
Request RequestScope
Session SessionScope
Application ApplicationScope
4) 1--EL表達式用${}表示,可用在所有的HTML和JSP標簽中作用是代替JSP頁面中復雜的JAVA代碼.
2--EL表達式可操作常量 變量 和隱式對象. 最常用的 隱式對象有${param}和${paramValues}.
${param}表示返回請求參數中單個字符串的值. ${paramValues}表示返回請求參數的一組
值.pageScope表示頁面范圍的變量.requestScope表示請求對象的變量. sessionScope表示會話
范圍內的變量.applicationScope表示應用范圍的變量.
3 --<%@ page isELIgnored="true"%> 表示是否禁用EL語言,TRUE表示禁止.FALSE表示不禁
止.JSP2.0中默認的啟用EL語言.
4-- EL語言可顯示 邏輯表達式如${true and false}結果是false 關系表達式如${5>6} 結
果是false 算術表達式如 ${5+5} 結果是10
5--EL中的變量搜索范圍是:page request session application 點運算符(.)和"[ ]"都是
表示獲取變量的值.區別是[ ]可以顯示非詞類的變量
2、EL隱含對象
1)與范圍有關的隱含對象
與范圍有關的EL 隱含對象包含以下四個：pageScope、requestScope、sessionScope 和
applicationScope；
它們基本上就和JSP的pageContext、request、session和application一樣；
在EL中，這四個隱含對象只能用來取得范圍屬性值，即getAttribute(String name)，卻不能取得
其他相關信息。
例如：我們要取得session中儲存一個屬性username的值，可以利用下列方法：
session.getAttribute("username") 取得username的值，
在EL中則使用下列方法
${sessionScope.username}
2)與輸入有關的隱含對象
與輸入有關的隱含對象有兩個：param和paramValues，它們是EL中比較特別的隱含對象。
例如我們要取得用戶的請求參數時，可以利用下列方法：
request.getParameter(String name)
request.getParameterValues(String name)
在EL中則可以使用param和paramValues兩者來取得數據。
${param.name}
${paramValues.name}
3.其他隱含對象
1)cookie
JSTL并沒有提供設定cookie的動作，
例：要取得cookie中有一個設定名稱為userCountry的值，可以使用${cookie.userCountry} 來
取得它。
2)header和headerValues
header 儲存用戶瀏覽器和服務端用來溝通的數據
例：要取得用戶瀏覽器的版本，可以使用${header["User-Agent"]}。
另外在鮮少機會下，有可能同一標頭名稱擁有不同的值，此時必須改為使用headerValues 來取得
這些值。
3)initParam
initParam取得設定web站點的環境參數(Context)
例：一般的方法String userid = (String)application.getInitParameter("userid");
可以使用 ${initParam.userid}來取得名稱為userid
4)pageContext
pageContext取得其他有關用戶要求或頁面的詳細信息。
${pageContext.request.queryString} 取得請求的參數字符串
${pageContext.request.requestURL} 取得請求的URL，但不包括請求之參數字符串
${pageContext.request.contextPath} 服務的web application 的名稱
${pageContext.request.method} 取得HTTP 的方法(GET、POST)
${pageContext.request.protocol} 取得使用的協議(HTTP/1.1、HTTP/1.0)
${pageContext.request.remoteUser} 取得用戶名稱
${pageContext.request.remoteAddr } 取得用戶的IP 地址
${pageContext.session.new} 判斷session 是否為新的
${pageContext.session.id} 取得session 的ID
${pageContext.servletContext.serverInfo} 取得主機端的服務信息
4) 條件標簽>
1.算術運算符有五個：+、-、*或$、/或div、%或mod
2.關系運算符有六個：==或eq、!=或ne、<或lt、>或gt、<=或le、>=或ge
3.邏輯運算符有三個：&&或and、||或or、!或not
4.其它運算符有三個：Empty運算符、條件運算符、()運算符
例：${empty param.name}、${A?B:C}、${A*(B+C)}
5) EL函數(functions)
語法：ns:function( arg1, arg2, arg3 …. argN)
其中ns為前置名稱(prefix)，它必須和taglib 指令的前置名稱一置
6) 補充：
<%@ taglib prefix="c" http://java.sun.com/jstl/core_rt">http://java.sun.com/jstl/core_rt" %>
FOREACH:
<c:forEach items="${messages}"
var="item"
begin="0"
end="9"
step="1"
varStatus="var">
……
</c:forEach>
OUT:
<c:out value="/${logininfo.username}"/>
c:out>將value 中的內容輸出到當前位置，這里也就是把logininfo 對象的
username屬性值輸出到頁面當前位置。
${……}是JSP2.0 中的Expression Language（EL）的語法。它定義了一個表達式，
其中的表達式可以是一個常量（如上），也可以是一個具體的表達語句（如forEach循環體中
的情況）。典型案例如下：
? ${logininfo.username}
這表明引用logininfo 對象的username 屬性。我們可以通過“.”操作符引
用對象的屬性，也可以用“[]”引用對象屬性，如${logininfo[username]}
與${logininfo.username}達到了同樣的效果。
“[]”引用方式的意義在于，如果屬性名中出現了特殊字符，如“.”或者“-”，
此時就必須使用“[]”獲取屬性值以避免語法上的沖突（系統開發時應盡量避免
這一現象的出現）。
與之等同的JSP Script大致如下：
LoginInfo logininfo =
(LoginInfo)session.getAttribute(“logininfo”);
String username = logininfo.getUsername();
可以看到，EL大大節省了編碼量。
這里引出的另外一個問題就是，EL 將從哪里找到logininfo 對象，對于
${logininfo.username}這樣的表達式而言，首先會從當前頁面中尋找之前是
否定義了變量logininfo，如果沒有找到則依次到Request、Session、
Application 范圍內尋找，直到找到為止。如果直到最后依然沒有找到匹配的
變量，則返回null.
如果我們需要指定變量的尋找范圍，可以在EL表達式中指定搜尋范圍：
${pageScope.logininfo.username}
${requestScope.logininfo.username}
${sessionScope.logininfo.username}
${applicationScope.logininfo.username}
在Spring 中，所有邏輯處理單元返回的結果數據，都將作為Attribute 被放
置到HttpServletRequest 對象中返回（具體實現可參見Spring 源碼中
org.springframework.web.servlet.view.InternalResourceView.
exposeModelAsRequestAttributes方法的實現代碼），也就是說Spring
MVC 中，結果數據對象默認都是requestScope。因此，在Spring MVC 中，
以下尋址方法應慎用：
${sessionScope.logininfo.username}
${applicationScope.logininfo.username}
? ${1＋2}
結果為表達式計算結果，即整數值3。
? ${i>1}
如果變量值i>1的話，將返回bool類型true。與上例比較，可以發現EL會自
動根據表達式計算結果返回不同的數據類型。
表達式的寫法與java代碼中的表達式編寫方式大致相同。
IF / CHOOSE:
<c:if test="${var.index % 2 == 0}">
*
</c:if>
判定條件一般為一個EL表達式。
<c:if>并沒有提供else子句，使用的時候可能有些不便，此時我們可以通過<c:choose>
tag來達到類似的目的：
<c:choose>
<c:when test="${var.index % 2 == 0}">
*
</c:when>
<c:otherwise>
!
</c:otherwise>
</c:choose>
類似Java 中的switch 語句，<c:choose>提供了復雜判定條件下的簡化處理手法。其
中<c:when>子句類似case子句，可以出現多次。上面的代碼，在奇數行時輸出“*”號，
而偶數行時輸出“!”。
經驗：1、如果EL表達式無法解析：– <%@ page isELIgnored="false" %>
一、 JSTL
1、EL運算符>;
2)var指定變量，并把EL運算結果賦值給該變量值為true/false；
3）scope:指定 var變量的范圍；
6、迭代標簽
語法：<c:forEach items=“collection” var=“name” varStatus=“status” begin=“int“
end=”int” step=“int” >
//循環體
</c:forEach>
說明:1)items:是集合，用EL表達式；
2)var:變量名，存放items
3)varStatus: 顯示循環狀態的變量
①index:從0開始;
②count:元素位置,從1開始;
③first:如果是第一個元素則顯示true;
④last:如果是最后一個元素則顯示true;
4)begin:循環的初始值(整型)；
5)end: 循環結束 ;
6)step:步長,循環間隔的數值；
7、<c:otherwise>標簽
例：
如果user.wealthy值true，則顯示user.wealthy is true.
<c:choose>
<c:when test="">
user.generous is true.
</c:when>
<c:when test="">
user.stingy is true.
</c:when>
<c:otherwise>
user.generous and user.stingy are false.
</c:otherwise>
</c:choose>
說明：只有當條件user.generous返回值是true時，才顯示user.generous is true.
只有當條件user.stingy返回值是true時，才顯示user.stingy is true.
其它所有的情況（即user.generous和user.stingy的值都不為true）全部顯示user.generous and
user.stingy are false.
由于JSTL沒有形如if (){…} else {…}的條件語句，所以這種形式的語句只能用<c:choose>、
<c:when>和<c:otherwise>標簽共同來完成了。
8、c:forTokens>標簽
說明：
items 進行循環的項目 是 無
delims 分割符 是 無
begin 開始條件 否 0
end 結束條件 否 集合中的最后一個項目
step 步長 否 1
var 代表當前項目的變量名 否 無
varStatus 顯示循環狀態的變量 否 無
例子:
<c:forTokens items="a:b:c:d" delims=":" var="token">
<c:out value=""/>
</c:forTokens>
這個標簽的使用相當于java.util.StringTokenizer類。在這里將字符串a:b:c:d以：分開循環四次，
token是循環到當前分割到的字符串。
9、<c:redirect>標簽
說明：標簽將請求重新定向到另外一個頁面，它有以下屬性 屬性 描 述 是否必須 缺省值
url url地址 是 無
context /后跟本地web應用程序的名字 否 當前應用程序
例子：
<c:redirect /'>http://www.yourname.com/login.jsp"/>
將請求重新定向到http://www.yourname.com/login.jsp頁，相當于response.setRedirect
("http://www.yourname.com/login.jsp");
10、<c:param>標簽
說明：<c:param>標簽用來傳遞參數給一個重定向或包含頁面，它有以下屬性屬 性 描 述 是否
必須 缺省值
name 在request參數中設置的變量名 是 無
value 在request參數中設置的變量值 否 無
例子：
<c:redirect url="login.jsp">
<c:param name="id" value="888"/>
</c:redirect>
將參數888以id為名字傳遞到login.jsp頁面，相當于login.jsp?id=888
11、<fmt:>格式化標簽
說明：需要導入 <%@ taglib prefix="fmt" http://java.sun.com/jsp/jstl/fmt">http://java.sun.com/jsp/jstl/fmt" %>
1）格式化日期<fmt:formatDate value=“” pattern=“yyyy-MM-dd HH:mm:ss”/>
Value:通過EL表達式或<%new Date() %> 取的日期值；
Pattern:輸出的日期格式；
2) 格式化數字<fmt:formatNumber
value="${n}" pattern="###,###.##" />
posted @
2010-07-02 11:41 justjavac(迷渡) 閱讀(899) |
評論 (0) |
編輯 收藏<!-- --> 這樣是行注釋的。也可以用作多行。。但是 可能有些瀏覽器 不支持CSS的 則跳過 <!-- --> 里面的內容繼續執行。。
/* */ 是 塊注釋的
jsp 注釋 // <!-- --> 已測試
HTML 注釋 <!-- --> 已測試，有的說這個/* */也能，但我試了好幾次它還是顯示
asp 注釋 ' 已測試
css 注釋 <!-- --> /* */
java 注釋 // /* */ /** */ 已測試
posted @
2010-07-02 11:38 justjavac(迷渡) 閱讀(136) |
評論 (0) |
編輯 收藏1.你可以打開一個窗口然后點擊，工具—文件夾選項—查看—顯示所有文件夾
選擇所要文件，右鍵屬性，將“隱藏”前面的勾去掉就可以。
還有另外一種方法，就是在開始-程序-附件-命令提示符下用dir -a 查看就可以看見隱藏的文件，
然后你再用Attrib -s -h -r “路徑和文件名”其中-s 表示減去系統屬性 -h 表示減去隱藏屬性 -r 表示減去只讀屬性。
另外你如果愿意的話還可以為文件加上以上的屬性,把-號變成+號就可以了。
2.選擇“工具→文件夾選項→查看→顯示所有文件和文件夾”，點確定。本來應該就把隱藏的文件顯示出來的，但是隱藏的文件并沒有顯示出來，重復上次操作發現“查看”中“隱藏文件和文件夾”一欄中它自動又跳為“不顯示隱藏文件和文件夾”這讓我很苦惱，因為我因此找不到我所有已經設置為隱藏的文件……
解決方法有三：
a.
運行regedit，找到[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL]，將CheckedValue的值改為1
b.
將下面的內容復制到記事本，保存為reg的注冊表信息文件，然后雙擊導入：
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL]
"RegPath"="Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced"
"Text"="@shell32.dll,-30500"
"Type"="radio"
"CheckedValue"=dword:00000001
c.
如果操作后還是無法顯示隱藏文件，可以復制下列內容到記事本中，另存為一個reg文件，然后雙擊運行即可。
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\NOHIDDEN]
"RegPath"="Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced"
"Text"="@shell32.dll,-30501"
"Type"="radio"
"CheckedValue"=dword:00000002
"ValueName"="Hidden"
"DefaultValue"=dword:00000002
"HKeyRoot"=dword:80000001
"HelpID"="shell.hlp#51104"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL]
"RegPath"="Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced"
"Text"="@shell32.dll,-30500"
"Type"="radio"
"CheckedValue"=dword:00000001
"ValueName"="Hidden"
"DefaultValue"=dword:00000002
"HKeyRoot"=dword:80000001
"HelpID"="shell.hlp#51105"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\SuperHidden]
"Type"="checkbox"
"Text"="@shell32.dll,-30508"
"WarningIfNotDefault"="@shell32.dll,-28964"
"HKeyRoot"=dword:80000001
"RegPath"="Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced"
"ValueName"="ShowSuperHidden"
"CheckedValue"=dword:00000000
"UncheckedValue"=dword:00000001
"DefaultValue"=dword:00000000
"HelpID"="shell.hlp#51103"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\SuperHidden\Policy]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\SuperHidden\Policy\DontShowSuperHidden]
@=""
說明：
將選項 CheckedValue 的值改成 0 然后再將系統屬性設置成不顯示隱藏文件，這樣，你隱藏的文件就徹底隱藏了，即使顯示全部文件，你隱藏的文件也不會顯示的。不僅如此，電腦里面所有隱藏文件將全部不被顯示。如果需要顯示，只要將選項 CheckedValue 的值改成 1 ，再將系統屬性設置成顯示全部文件即可。
3.問題：
我使用的是Windows2000系統,我把"文件夾選項"中的"查看"設為"不顯示隱藏的文件和文件夾"時,電腦上隱藏的文件反而能看見,設為"顯示所有文件和文件夾"時,這些文件反而隱藏了,這是怎么回事?
解決：
在運行中輸入regedit,打開注冊表編輯器.定位到HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\NOHIDORSYS,將CheckedValue設置為0；再定位到HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL,將CheckedValue設置為1即可。
posted @
2010-07-02 11:36 justjavac(迷渡) 閱讀(139) |
評論 (0) |
編輯 收藏 <一>
你不會有那美麗的相逢，除非之前,你能忍受等待的孤獨.
你不會有那明朗的清晨，除非之前，你的睡夢能忍受黑夜的迷霧。
你也不會贏得任何東西，除非你敢于投下賭注.
賭注，生命的賭注,就是你的腳步!
但是你不會找到路，除非你敢于迷路.
因為，只有讓你迷路的地方，才是你真正的出路!
<二>
有多少次此刻的離別，就有多少次彼時的相逢.
有多少次此刻的酒醉，就有多少次彼時的痛醒.
所以你應該理解一個人的沉默,就是一個人最多的話語.
你也應該理解一個人的憂傷,之所以憂傷，一定是因為他不肯舍棄某些快樂.
<三>
暖一壺茶,在寒冷的冬季里,讓溫氣升騰,但朋友，別忘了,除了爐火,還有那寒風賜予了這壺茶以溫度.
我相信，最溫暖來自寒冷.我相信，最溫暖,其實是對寒冷的一種諒解.
<四>
生命確實有兩層-----
一個浪打礁石，海鳥驚逃，以為是一次謀殺，
一個浪撲上海灘，孩子歡喜，以為是大海開出了鮮花．
同樣的事物，有不同樣的感受．
所以世界是什么樣的，并不重要，重要的是生命的心靈。
世界往往是什么樣子，往往取決于你的心靈是什么樣子．
莫要過分誤解這個世界，請先看看自己的心靈的模樣．
＜五＞
愛的方式有許多種，
而愛是一種動機，愛的動機是誠實而純潔的，
但愛的方式卻不可靠。
即使你有愛，你愛著，可你愛的方式是否避免著偏執－－－
朋友，請不要采摘那些花朵，除非你能保證，一起搬走整個森林的田野
>>>>>>查看posted @
2010-07-02 11:34 justjavac(迷渡) 閱讀(146) |
評論 (0) |
編輯 收藏 當母親帶著疲憊的微笑將你捧給世界，你已經是一座高山，是一片大海了。性別交給你一副重擔，指給你一條路，對你說：走吧，你這男子漢！于是你便要長一副錚錚鐵骨，把腳下堅實的土地踏得咚咚作響，去完成你的使命、你的光榮、你的答卷。
當洪水涌來的時候，你要退在最后；當大火燃燒的時候，你卻要撲在前邊。因為你是男人，你就應該有一副俠肝義膽！
當朋友成功的時候，你要大碗喝酒；與女友分手時，要真誠地說聲道歉。因為你是男人，你就應該如此氣壯心寬。
因為你是男人，所以，對女兒你應是一棵結滿故事的大樹，對妻子你應是一片金色的沙灘，對父母更該是一座物產豐富的大山。
因為你是男人，一生就要有所成就。不懶惰，不僥幸，不虛榮，不欺騙，不流淚，不妒嫉，不后悔，不自卑，不獻媚，不投機，不唯利是圖，不 抱怨，男人就應該堂堂正正、磊磊落落、風度翩翩。
做個好男人也是一項事業啊。一個民族僅有女人的光榮是不夠的，陰盛陽衰對每個男人來說都應該覺得行穢自慚。
也許你很矮，但好男人博大的胸懷才情會使你頂天立地；也許你很弱，但好男人堅定的意志品格將賦予你狹義鐵肩；也許你惡疾纏身，但好男人的字典里根本沒有傷殘。
男人，光榮的性別。這光榮的全部內涵就在于去承擔責任和義務做出犧牲和奉獻。做個好男人吧！你別無選擇，因為你已經是個男人了。
>>>>>>>查看posted @
2010-07-02 11:33 justjavac(迷渡) 閱讀(158) |
評論 (0) |
編輯 收藏