模板
教程
環境
性能
功能
管理
與PHP開發有關的模板問題
用PHP 開發 WEB程序時,都有哪些模板它們的區別又都是什么?謝謝了! 我只知道有smarty,phplib模板,但也不知道他們的區別是什么.請高手指點! shukebeita 回復于：2004-02-19 11:29:21 關于PHP的模板的確是一個說起來容易做起來麻煩的事情。隨便一數大概有20種以
用PHP開發WEB程序時,都有哪些模板它們的區別又都是什么?謝謝了!
我只知道有smarty,phplib模板,但也不知道他們的區別是什么.請高手指點!
| shukebeita 回復于：2004-02-19 11:29:21 |
| 關于PHP的模板的確是一個說起來容易做起來麻煩的事情。隨便一數大概有20種以上的選擇，光pear里面就包含了5中不同的模板，實在讓人頭疼。
千萬不要人云亦云的說這個好那個不好，選擇模板之前最好先應該搞清楚模板的真正目的是什么？ 簡單地說，模板的核心目的就是一個 team work。主要的作用方式有兩種： 1、分離HTML和PHP使網頁設計師和PHP程序員合作更加愉快。 2、分離顯示邏輯和事物邏輯，使得核心事務邏輯的變更和應用程序的擴展更加容易和靈活，也就是說使得程序員之間合作更加愉快。（這一點經常被人們忽視或者誤解，總以為把PHP從HTML中弄出去就叫分離顯示邏輯和事物邏輯了，如果這樣當初又何苦讓PHP和html 混在一起呢？） 搞清楚這個模板的真正目的是什么，就容易做出正確的選擇了。 如果只有你一個php程序員但是需要和其他的網頁設計人員一起協同工作，那么選擇能夠分離HTML和PHP的模板就可以了，phplib （現在好像集成到 Pear 里面了 http://pear.php.net/package/HTML_Template_PHPLIB）或者 FastTemplate 都是這樣的東西，很簡單容易上手。 如果你的網站界面比較丑陋并且主要由程序員來完成，但是功能比較復雜更需要強大的擴展功能，需要分離各個層次包括顯示邏輯，那么不要用什么特別的東西，PHP本身就是最好的模板了。要注意的是在這種情況下，你要非常認真的設計你的程序，始終記住要分離的不是PHP和 html 而是事務邏輯(business logic )和顯示邏輯(presentation logic)。這也是為什么我一直對于Smarty 這種東西非常的抵觸， 因為這個 Smarty 的語法太復雜了太強大了， 幾乎重新發明了一種腳本語言東西， （即使是PHP的程序員也要重新學習它）。更讓人費解的是 這種腳本 越是強大，越容易讓人將事務邏輯(business logic )和顯示邏輯(presentation logic)混在一起， 破壞了模板的初衷。 如果你既想HTML和PHP分離，得到更好的視覺設計，又想整個系統有非常強大的擴展能力能夠適應html,xml,wml各種界面，而且不用去學習復雜的語法的同時提供較高的運行效率，那么這就是一個相當有挑戰性的問題了。壞消息是目前還沒有一個成熟的模板真正能夠達到這樣的要求，好消息是完成這樣的一個模板并不是很難，如果你嘗試過Zope或者是ColdFusion就會發現這種模板的影子， （wact http://wact.sourceforge.net/ 和 phptal http://phptal.sourceforge.net/ 就是在向這個方向發展，應該很有前途）。 模板和數據的結合（模板的調用）方式主要有兩種：推的方式和拉的方式。 推的方式是用PHP將數據推給模板，就是說需要程序員明確地為模板中的每一個變量賦值，將他們綁起來。 而拉的方式則像把php 和 html 混在一起一樣，模板種的變量主動把數據拽進來。 說到模板就不能不提到另外兩種東西： phphtmllib 和 quickform(http://pear.php.net/package/HTML_QuickForm) 這兩種東西是用傳統的方式來通過各種頁面構件來完成HTML的頁面的 整個頁面的構造完全掌握再程序員手里，也許很多編寫過傳統GUI桌面程序的程序員更喜歡這種方式。 更加漂亮的方案 如果做商業軟件的話，Flash應該是更漂亮的方案（別搞錯了，別以為就你知道php支持ming 和swf庫可以動態生成 Flash，我說的不是這個。） 我要說的是支持Flash Remoting 的方案，這種東西才是真正有意義的PHP和flash的結合。由視覺設計師完成flash部分，PHP 程序員通過 flash remoting 的方式將 數據發送到 flash 做成的客戶端中。 目前有兩種方案： AMFPHP http://www.amfphp.org/ 由于Macromedia Flash Remoting 傳輸數據時 使用的是一種特有的更加高效數據格式， 所以AMFPHP通過分析數據格式，在服務器端構造了相應的php類來接收，解析和編碼這些數據從而達到交換信息的功能（就像Samba一樣，應該屬于一種 Hacking 吧）。 PHPObject http://ghostwire.com/resources/phpobject/ PHPObject 則采用了另外一種方法，通過在flash中嵌入一些actionscript的組件通過開放的格式soap來傳送數據。 其實關于PHP的模板還牽扯到很多其它的問題，一時半會我也只能寫這么多了，有時間了我會寫到書里的。 你的想法呢？ |
| 飛雪恨水 回復于：2004-02-19 12:01:30 |
| 我也不知道該用什么模板了 |
| longnetpro 回復于：2004-02-19 15:14:49 |
| 同意二樓的。我一般不用什么所謂的HTML模板，而多用二樓說的那種事務邏輯與表示邏輯分開。就是說，顯示邏輯用單獨的單元，事務邏輯則用OO來封裝，有些類似于JAVA的SERVLET和JAVABEAN進行二層分離。同時，為了能與網頁設計人員配合，即同時又做到代碼與HTML分離，我采用二次編譯模板的辦法。即在最初的元素為資源文件與框架文件，然后將這兩種文件進行第一次編譯，組合成不含代碼的模板文件，由網頁設計人員對這個模板文件進行修改，這個文件中含有少量特殊語法標記，但不復雜，主要是些變量與格式及少量及必要的流程控制。設計人員完成之后，對模板進行第二次編譯，生成顯示邏輯的PHP腳本，就是說將模板編譯成直接可用的PHP腳本，而且只涉及顯示。事務邏輯在顯示邏輯之前運行，一般只調用類的實例即可，顯示邏輯中的變量都可以與事務邏輯相關聯，其實這里就用到了二樓說的拉的方式，也就是在顯示邏輯中，代碼與HTML是混在一起的，但主要功能是顯示界面，而事務處理，如從數據庫中取數據等都在事務層處理了。只是這個最后的顯示邏輯一般不用自己寫PHP腳本，而可以直接從模板中編譯出來。用這種拉數據的方式比用推的方式效率要高，因為對PHP解釋器來說，它無須兩次解析（其中一次是用腳本解析模板）。用這種預編譯的方式一般來說只須生成一次顯示邏輯即可，以后就直接用了，無需每次都要象PEAR中的那些模板在運行時人為解析。用二次編譯的方法還可以做到高度易擴展性，資源文件中只有純常量，結構文件中只有純結構，資源文件中的常量可以改成各種語言，結構文件可以不變，兩者經過第一次編譯與合成生成真正的模板文件，它不含任何PHP語法，只有一些放在<!--@ 與 -->之間的結構標記與混合了資源文件中字符串的HTML頁面，這時可以供網頁設計人員進行隨意修改，修改完后，經過第二次編譯，直接生成表示層的PHP腳本，這時該腳本就是PHP代碼與HTML代碼混合的。
我對模板進行了規劃，而且寫了這么幾個類：ResourceLoader, BlockPrecompiler, BlockCombiner, TemplateCompiler 第一次編譯前的結構文件叫block，各個block可以單獨編譯，也可以一起編譯，編譯完了按main block的結構將被包含的block組合進來生成一個模板文件——這個文件就是供網頁設計人員修改的文件，當然也可以修改第一次編譯后的各個小block，然后再組合。大致的流程是： 1、先用ResourceLoader從指定的語言包資源文件中調入資源，并解析，生成一個數組放在這個類中； 2、用BlockPrecompiler預編譯指定的block，既可手工單獨編譯，也可根據主入口block的文件包含情況自動地批量編譯，對已存在的編譯過的block可以選擇覆蓋或是保留（手動，類方法不會根據文件時間自動判斷是否覆蓋，因為考慮到網頁設計人員可能會自己修改編譯后的block）； 3、用BlockCombiner根據主block入口文件中的信息將已編譯的block進行包含組合，生成一個模板文件，以供網頁設計人員修改。該類只進行組合，不編譯，除非發現被包含的文件尚未被編譯，但主入口block必須被預編譯，否則將會錯誤退出?？傊褪潜ＷC這些block至少被編譯一次，如果要求覆蓋則強制再編譯。生成的模板文件不含PHP代碼； 4、網頁設計人員修改經過一次編譯的模板文件； 5、用TemplateCompiler對網頁設計人員修改過的模板文件進行第二次編譯，生成對應顯示邏輯的PHP腳本文件，以供程序使用。 這么做主要是考慮到模板修改不是那么頻繁，而使用模板卻很頻繁，因此最好的辦法是直接用PHP與HTML混合這個固有的優勢，而不是機械地強調代碼與HTML完全分開（完全分開其實是極為愚蠢的想法）。之所以要分開主要是為了網頁設計人員的方便與透明而不完全是為了程序本身——程序本身只要做到兩個邏輯層分開就足夠了，通過模板的二次編譯基本上比較好地解決了這個矛盾，而且同時也實現了事務邏輯與顯示邏輯分開。由于模板語法設計并不復雜，設計時也盡量做到簡單與嚴格，因此這幾個類的源程序也不大，僅18.2K，加上一些輔助的函數，總共不超過22K，主要也還是利用了強大的正則表達式。而且它們一般在寫WEB應用程序時是用不到的，主要是在寫模板編譯環境的程序時才會用到，因為在WEB程序中要用模板時，只需要簡單地include一下第二次編譯后的文件就可以了。 至于說用FLASH+PHP，這個我也干過，用標準XML的方法可以做任何事，后臺的PHP可以不必有任何顯示性輸出，它輸出的是標準的XML數據，主要是前臺的FLASH將返回的結果顯示出來。不過說實話，這個玩意限制比較大，比如說UNICODE就是一個問題，雖說FLASH6以上對UNICODE支持好多了，但它目前還是支持得不夠，至少三個字節的UNICODE它就支持得不好，而且有時還不太方便。其實說穿了，這個FLASH+PHP其實就是在SERVER與CLIENT端之間傳遞XML格式的數據，后臺處理用服務器端的PHP，前臺顯示用客戶端的FLASH，與最老的C/S的應用程序從實質上來說沒有什么區別，唯一的區別是傳遞數據用的高層協議不同，這時PHP本身就是服務器。 |
| shukebeita 回復于：2004-02-19 15:51:16 |
| 不知道longnetpro能不能把你的那幾樣寶物（ResourceLoader, BlockPrecompiler, BlockCombiner, TemplateCompiler）拿出來曬曬，頁好讓小的們開開眼。最好加上一個簡簡單單的例子。 :-) |
| longnetpro 回復于：2004-02-19 17:59:22 |
| 那是沒有問題的，不過現在還不行。因為我現在做的是一個框架，這個模板編譯單元只是整個框架的一個模塊，單獨拿出來可能不能運行，而且我的例子與WEB程序也是建立在我這個框架上。這個框架就是我說的用了DELPHI工程的架構，庫與程序單元是分開的，目錄搬移是沒有任何問題的，一些純靜態的媒體文件如圖片等還可以放在另一臺不支持PHP的主機上。
到目前為止，共做了大概上十個模塊，計有： 1、打包壓縮（TAR及TGZ，直接封裝各種功能，計添加文件，刪除文件，解包，列表，更新，添加更新等，全部支持批量操作，并支持通配符，支持子目錄遞歸壓縮，文件名大小寫敏感可自定）已完成 2、編碼轉換（GB18030,GBK,GB2312、BIG5、UTF8,16,32互轉，中文繁簡互轉，中文字符串及子串精確長度等；有擴展規范，可方便地擴展到日文，韓文等，內部編碼用UCS4。以上轉換除中文繁簡互轉可能有偏差外，其它都是精確轉換）已完成 3、時間處理（精確處理世界各時區——時區精確到十五分鐘，WIN2K區域設置中的時區全有，對同一個時區但不同的地方有不同的處理方式；精確全面地處理世界各地夏令時——計算誤差一般不會超過2秒，所有夏令時的起止點全部參考WIN2K的時區設置，例如加拿大東部時間從每年四月的第一個星期日凌晨二點開始夏令時到每年十月的倒數第一個星期日的凌晨二點為止等等，不過夏令時信息尚未輸入，太多了，只是做好了接口；還有計算生肖、星座等——生肖精確到農歷新年，星座精確到天；所有與時間有關的計算用UNIX時間戳，輸出為轉換后的時間戳；有關生肖與星座的計算輸出用整數，因此無本地化的問題） （上星期更新：改寫了時間日期模塊的部分內容，使時間戳支持從公元元年到9999年，彌補了UNIX時間戳的不足，并增加了1582年的日期修正，閏年判斷也相應調整，星期幾的計算也相應地針對1582年的修正加以調整，能計算某年某月某日與公元元年一月一日的距離，起點以每日00:00:00開始計算，絕對精確。同時兼容UNIX時間戳，就是說在1970到2038年之間的時間戳與擴展后的時間戳一致。時區計算也采用新的函數，但接口不變。新增計算符合ISO8601規范的日期）已完成 4、權限系統（二維權限，可定義用戶及用戶組，支持允許與拒絕權限，可定義預設組權限，可定制某個具體空間的策略，可動態設定某用戶在某空間是否在預設組——重載幾個方法即可，用一個方法調用即可知道某用戶在某空間的具體權限；所有的參數全部為字符串輸入，方便存貯在數據庫中）已完成 5、分頁（這個不用多說了吧，支持上頁、下頁、首頁、尾頁、上幾頁、下幾頁，支持直接跳轉到第幾頁；每頁顯示記錄數準確；可容錯，如果輸入參數錯誤可自動更正）已完成 6、文件鎖（兩種鎖方式——系統鎖及模擬鎖，可人為指定方式，但不支持自動檢測，因為那不是這個類應該做的事；支持文件鎖定——包括共享鎖定和排他鎖定；除了文件鎖定外還支持頁面鎖定——只鎖定一個文件的部分頁面，不過只支持寫鎖定，讀數據不能鎖定，這種頁面鎖定也可改成單條記錄鎖定，原理差不多）已完成 7、通用數據庫接口（簡單的，目前只支持MYSQL，可擴展，可支持限制查詢LIMIT——接口通用，只需重載幾個方法即可，但功能不復雜，也不是最完善的，寫完善的太多了，對我來說也沒有必要）這一部分已完成了 8、二次可編譯模板（支持資源文件、語言包、定制的流程控制，模板與代碼完全分離；資源文件用自定義的格式，清楚明了，尤其便于翻譯，無需在整個HTML文件中找零散的文字進行翻譯，而只需對資源文件中的條目一一對應翻譯即可，而這些條目支持是支持格式輸出的；語言包還支持單復數的不同——類似于JAVA中的本地化；二次編譯模式，第一次從一組資源文件、語言包和流程控制文件編譯成模板文件，該模板文件可供美工自行修改，不含程序代碼；美工完成后，再由程序進行第二次編譯，生成可發布的PHP腳本文件，當然也可以在使用時動態編譯）已完成 9、緩存（尚未開始，還需重新構思）過一陣子再寫它 10、標簽系統（尚待完善，原來寫過一個，思路不錯，但效率偏低，現準備重新設計流程；原理：將字符串編譯成中間代碼存貯，可正轉也可逆轉，存在數據庫中的是中間代碼，需要編輯的時候就逆轉，需要顯示的時候就正轉，逆轉比較快，只要去掉相應的標記即可，正轉時由于需要轉的是中間代碼，不用再分析，而是直接替換即可。只有在往數據庫里寫的時候才需要把最原始的明文轉編譯成中間代碼，這個需要一點時間和資源，但因為一般寫的機會比較少，因此還是值得的。此標簽系統特點是：標簽嚴格，安全性好，不會出現什么破壞現象，也不會有什么漏洞；標簽可任意交叉重疊而不會導致頁面被破壞，因為我在編譯時用了堆棧來判斷，凡是不能匹配的全都不算合法標簽，而不是僅僅只用正則替換；擴展性好，只需重載某些函數即可）這個太復雜了，上次斷斷續續寫了一兩個月，這一次看來時間也不會太短。 還有其它一些模塊，包括自己寫的與修改別人的，大部分用OO寫成。還有一些庫函數等等。 對了，所有的這些模塊，與界面都沒有任何關系，全是類與函數，只處理事務，不顯示輸出具體內容，要具體顯示，可用繼承的方法來實現。 |
| shukebeita 回復于：2004-02-20 22:49:52 |
| 原來有這么多的寶物。對于其中的壓縮打包和時間處理比較感興趣能不能發來看看。phpbloobook at yahoo dot com dot cn .
另外，你的那個什么標簽系統是什么意思？不太明白，干什么用的呢？ |
| longnetpro 回復于：2004-02-21 00:18:32 |
| 樓上的留下MSN，聯系比較方便 |
| PHPstupid 回復于：2004-02-21 11:46:42 |
| 樓上的也太強了
佩服佩服 我的MSN是chlbtfeichl@hotmail.com 如果上面兩位高人不嫌小弟水平低的話可以加我 大家共同交流交流 |
| rainren 回復于：2004-04-28 15:29:44 |
| [quote:91b818e5a9="longnetpro"]那是沒有問題的，不過現在還不行。因為我現在做的是一個框架，這個模板編譯單元只是整個框架的一個模塊，單獨拿出來可能不能運行，而且我的例子與WEB程序也是建立在我這個框架上。這個框架就是我說的用了DELPHI工程?.........[/quote:91b818e5a9]
高人! 能讓我學學嗎? 看看代碼嗎? 謝謝! :em03: :em03: :em03: |
| HonestQiao 回復于：2004-04-28 20:16:25 |
| http://w.yi.org/ftp/FAPM模板專輯 |
| hightman 回復于：2004-04-30 00:54:27 |
| 致 HonestQiao:
好像你也是用 FreeBSD操作系統,我有個問題想請教你一下, 不知你碰到過沒有. FreeBSD 4.5 上的運行著 mysql-4.x , 雖然有比較多的并發連接,但這個MYSQL肯定是有問題的, TOP 時可以清楚看到 mysqld 占用的cpu高大 69%或更多, 好幾臺 FreeBSD 都如此, 而相同負載的 linux 機器上的mysqld卻負荷不高. 查閱過許多資料,見網上有討論說 FreeBSD對線程支持不好,導致的... :( 請問你碰到過嗎,有什么好辦法? thx |
原文轉自：http://www.anti-gravitydesign.com
