| 導購 | 订阅 | 在线投稿
分享
 
 
 

詳細解析:關于PHP事件驅動問題

來源:互聯網  2008-12-22 08:07:58  評論

事件驅動這個概念是廣義的。可以在客戶端,也可以在服務器端。

在WEB應用上,在客戶端的事件是基于JS或是插件或是JAVAAPPLET之類的東西,基本上如果是插件或是JAVAAPPLET的話,就不屬于 HTML的範疇了,而真正必須用到JS的場合其實並不多,最多就是FORM的提交或是鏈接點擊之類的基本操作,因此談論事件無太大意義。

事件驅動真正的意義並不在于可視化編程,而在于它的概念,就象OO一樣。事件驅動其實是OO的一個延伸,它的最初原型是消息機制。但是事件驅動把消息封裝成了一個可調用的函數,有些類似于API中的回調函數,你自己可以定義這些函數執行的內容。而可視化編程則把這些函數獨立出來,定義好參數(多數是現成的對象),讓你自己寫代碼並運用這些參數(其實是用這些對象)做一些事情。

所以,PHP有事件驅動是完全可能的,主要在于框架的設計。而要做成VB之類所謂的可視化事件驅動,則必須要有配套的集成開發環境,包括頁面設計,事件編碼,編譯轉碼之類的一系列功能才行。其實象點NET這樣的事件驅動,只不過是把一些常用的WEB元素或控件,如按鈕、文本框之類的東西封裝了一下,讓你有個可視化的界面可以設計一下,當它編譯之後,仍然是之類的文本,只是把你的事件代碼轉爲了JS或是服務器端代碼而已。而PHP主要是由于IDE不夠豐富,而且也沒有預編譯機制,所以最後提交的代碼還是最終的PHP代碼,而不是點NET的資源代碼與事件代碼的混合體(一般是符合XML規範的ASP文檔,包含了非標准的HTML代碼)。故此PHP還無法達到大家心目中狹義的所謂事件驅動編程,但其實是完全可以沒有問題的。

如果大家感興趣,不妨到www.php.net官方主頁去看一下一位中國哥們(Qiang Xue)寫的一套基于事件驅動的PHP框架PRADO,這個還是獲得高票當選的最佳,強烈推薦!請參考http://www.zend.com/php5/contest,你看了他的源代碼後就會理解PHP的事件驅動是怎麽回事。但我認爲,在這上面,由于PHP無預編譯機制,而且過度依賴OO(雖然是用PHP5寫的代碼),造成這個框架有些龐大,且使用比較複雜,可擴展性也不是很好。不過,其中的理念非常之好,有些想法還解決了困惑我多日的問題。我下面簡單介紹一下這個框架。

該框架用ZDE及PHP5寫成,有詳細文檔,結構十分清晰,注釋極爲充分,代碼非常易于讀懂,說明作者寫碼水平非常之高。作者明確說明,這套框架參考了ASP點NET及Borland Delphi的概念。

這個框架在驗證性上非常之強(並不是指裏面有什麽驗證登錄之類的模塊),十分健壯,幾乎不可能有什麽直接的漏洞可以從外面攻入,它是引入了規範文件這個概念做限制,很有效地解決了大量驗證時的效率瓶頸,這種驗證方法只有一個問題就是規範文件本身的制作比較費力(當然用工具的話是另一回事了),然而一旦做好(規範文件本身有格式與規範的),驗證就自然而然地由框架去做了,而無需每次人爲調用。它的事件也可以定義在規範文件之內(我卻認爲這就沒有必要了),其實它的規範文件就有點類似于DELPHI或是VB中的FORM定義文件,只不過是用XML寫的純文本,而非可視化。而對于事件驅動,框架內置了一套與點NET類似的基本事件流,你可以在不同階段定制這些事件,其實說白了,就是重新定義這幾個OnXXX函數,用給定形式的參數,你也可以自己加入自己的事件,比如你在定義自己的組件時,在規範文件中定義好該組件可能有的事件函數及參數,以後你在使用該組件時可以直接定義這些被允許的函數——不過我認爲這種方式過于複雜,且要大量讀入並分析XML文件,雖然十分地嚴謹,很安全,但有些過分了,也沒有充分利用到PHP本身的靈活性,我的思路是用類似于 DELPHI的函數句柄賦值的辦法或是用C的回調函數的特性,即可在寫代碼時在任何時間任何地點定義事件,而仍然能明確事件發出者及類型並有足夠地安全性保證,且無需機械地強制各個組件只能有哪些事件,代碼修改及擴展都十分方便。當然,在做大項目的時候,嚴格的定義是必要的,不過,即使如此,該框架處理事件的方法還是有些古板。

它的模板我認爲是一個比較好的想法,它的模板有些類似于點NET的ASP文件在編譯前的文件(我對ASP點NET並不熟,但明白一些原理),但起作用的方式則類似于DELPHI的FORM文件,是一個很好的概念,唯的一缺點是用DW之類所見即所得的通用編輯器則感覺不是很順手,因爲一個模板中可以同時把幾個互斥的組件放在一起,而只在運行過程中決定顯示哪些。

就我本人看該框架的代碼,還是發現它有一些非常弱的項。其中最主要的一個就是路徑的問題,可擴展性很低,應該比較適用于專用主機,對一些受限主機 (目錄限制或是權限限制)就無能爲力了,也無相應的提醒措施(也無相關接口)。它對某些資源或文件的路徑,用了一種繁瑣的叫assetService的機制,目的就是確定文件的路徑,作者自己也說,如果用了這個服務,系統消耗會明顯增加,其實這個是借鑒了FLASH中asset library的概念,它這樣雖然可以任意指定路徑,但每次都必須重新校驗,有些得不償失。我的作法則是固定好幾個主要路徑,而其的子目錄都可隨意,就綜合平衡了兩者的矛盾。由于對路徑問題缺乏考慮,導致該框架對語言設置、個性化模板等無能爲力,如要翻譯一個項目,手續之繁,工作量之大是可想而知的,而且極易出錯。這是該框架中最嚴重的一個問題。

從總體上來說,該框架的理念上,設計上,代碼上絕對都屬一流。當然不足總是有的,不過完全不妨礙我們研究及學習它。它的代碼我並未全看,只主要看了幾個核心程序及一些說明,但已能足夠看清楚其結構與思想,對作者深表佩服,但對其中的不足也深表遺憾。不管怎麽樣,它都絕對是研究PHP事件驅動代碼的好作品。因此強烈推薦!

事件驅動這個概念是廣義的。可以在客戶端,也可以在服務器端。 在WEB應用上,在客戶端的事件是基于JS或是插件或是JAVAAPPLET之類的東西,基本上如果是插件或是JAVAAPPLET的話,就不屬于 HTML的範疇了,而真正必須用到JS的場合其實並不多,最多就是FORM的提交或是鏈接點擊之類的基本操作,因此談論事件無太大意義。 事件驅動真正的意義並不在于可視化編程,而在于它的概念,就象OO一樣。事件驅動其實是OO的一個延伸,它的最初原型是消息機制。但是事件驅動把消息封裝成了一個可調用的函數,有些類似于API中的回調函數,你自己可以定義這些函數執行的內容。而可視化編程則把這些函數獨立出來,定義好參數(多數是現成的對象),讓你自己寫代碼並運用這些參數(其實是用這些對象)做一些事情。 所以,PHP有事件驅動是完全可能的,主要在于框架的設計。而要做成VB之類所謂的可視化事件驅動,則必須要有配套的集成開發環境,包括頁面設計,事件編碼,編譯轉碼之類的一系列功能才行。其實象點NET這樣的事件驅動,只不過是把一些常用的WEB元素或控件,如按鈕、文本框之類的東西封裝了一下,讓你有個可視化的界面可以設計一下,當它編譯之後,仍然是之類的文本,只是把你的事件代碼轉爲了JS或是服務器端代碼而已。而PHP主要是由于IDE不夠豐富,而且也沒有預編譯機制,所以最後提交的代碼還是最終的PHP代碼,而不是點NET的資源代碼與事件代碼的混合體(一般是符合XML規範的ASP文檔,包含了非標准的HTML代碼)。故此PHP還無法達到大家心目中狹義的所謂事件驅動編程,但其實是完全可以沒有問題的。 如果大家感興趣,不妨到[url=http://www.php.net]www.php.net[/url]官方主頁去看一下一位中國哥們(Qiang Xue)寫的一套基于事件驅動的PHP框架PRADO,這個還是獲得高票當選的最佳,強烈推薦!請參考[url=http://www.zend.com/php5/contest]http://www.zend.com/php5/contest[/url],你看了他的源代碼後就會理解PHP的事件驅動是怎麽回事。但我認爲,在這上面,由于PHP無預編譯機制,而且過度依賴OO(雖然是用PHP5寫的代碼),造成這個框架有些龐大,且使用比較複雜,可擴展性也不是很好。不過,其中的理念非常之好,有些想法還解決了困惑我多日的問題。我下面簡單介紹一下這個框架。 該框架用ZDE及PHP5寫成,有詳細文檔,結構十分清晰,注釋極爲充分,代碼非常易于讀懂,說明作者寫碼水平非常之高。作者明確說明,這套框架參考了ASP點NET及Borland Delphi的概念。 這個框架在驗證性上非常之強(並不是指裏面有什麽驗證登錄之類的模塊),十分健壯,幾乎不可能有什麽直接的漏洞可以從外面攻入,它是引入了規範文件這個概念做限制,很有效地解決了大量驗證時的效率瓶頸,這種驗證方法只有一個問題就是規範文件本身的制作比較費力(當然用工具的話是另一回事了),然而一旦做好(規範文件本身有格式與規範的),驗證就自然而然地由框架去做了,而無需每次人爲調用。它的事件也可以定義在規範文件之內(我卻認爲這就沒有必要了),其實它的規範文件就有點類似于DELPHI或是VB中的FORM定義文件,只不過是用XML寫的純文本,而非可視化。而對于事件驅動,框架內置了一套與點NET類似的基本事件流,你可以在不同階段定制這些事件,其實說白了,就是重新定義這幾個OnXXX函數,用給定形式的參數,你也可以自己加入自己的事件,比如你在定義自己的組件時,在規範文件中定義好該組件可能有的事件函數及參數,以後你在使用該組件時可以直接定義這些被允許的函數——不過我認爲這種方式過于複雜,且要大量讀入並分析XML文件,雖然十分地嚴謹,很安全,但有些過分了,也沒有充分利用到PHP本身的靈活性,我的思路是用類似于 DELPHI的函數句柄賦值的辦法或是用C的回調函數的特性,即可在寫代碼時在任何時間任何地點定義事件,而仍然能明確事件發出者及類型並有足夠地安全性保證,且無需機械地強制各個組件只能有哪些事件,代碼修改及擴展都十分方便。當然,在做大項目的時候,嚴格的定義是必要的,不過,即使如此,該框架處理事件的方法還是有些古板。 它的模板我認爲是一個比較好的想法,它的模板有些類似于點NET的ASP文件在編譯前的文件(我對ASP點NET並不熟,但明白一些原理),但起作用的方式則類似于DELPHI的FORM文件,是一個很好的概念,唯的一缺點是用DW之類所見即所得的通用編輯器則感覺不是很順手,因爲一個模板中可以同時把幾個互斥的組件放在一起,而只在運行過程中決定顯示哪些。 就我本人看該框架的代碼,還是發現它有一些非常弱的項。其中最主要的一個就是路徑的問題,可擴展性很低,應該比較適用于專用主機,對一些受限主機 (目錄限制或是權限限制)就無能爲力了,也無相應的提醒措施(也無相關接口)。它對某些資源或文件的路徑,用了一種繁瑣的叫assetService的機制,目的就是確定文件的路徑,作者自己也說,如果用了這個服務,系統消耗會明顯增加,其實這個是借鑒了FLASH中asset library的概念,它這樣雖然可以任意指定路徑,但每次都必須重新校驗,有些得不償失。我的作法則是固定好幾個主要路徑,而其的子目錄都可隨意,就綜合平衡了兩者的矛盾。由于對路徑問題缺乏考慮,導致該框架對語言設置、個性化模板等無能爲力,如要翻譯一個項目,手續之繁,工作量之大是可想而知的,而且極易出錯。這是該框架中最嚴重的一個問題。 從總體上來說,該框架的理念上,設計上,代碼上絕對都屬一流。當然不足總是有的,不過完全不妨礙我們研究及學習它。它的代碼我並未全看,只主要看了幾個核心程序及一些說明,但已能足夠看清楚其結構與思想,對作者深表佩服,但對其中的不足也深表遺憾。不管怎麽樣,它都絕對是研究PHP事件驅動代碼的好作品。因此強烈推薦!
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
王朝網路微信公眾號
微信掃碼關註本站公眾號 wangchaonetcn
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有