2009-02-14 44 views
3

我注意到一個PHP框架; Zend,CakeSymfony;似乎要麼生成JavaScript,要麼允許它作爲一個字符串嵌入到PHP本身中。這是一個好主意嗎?從使用過這些框架/庫的人員中,您使用Ajax和JavaScript助手的經驗是什麼?它容易維護嗎?它減少了開發時間嗎?PHP框架應該生成JavaScript嗎?

回答

13

不,它是一個壞主意,

生成的JavaScript通常意味着該網站將無法使用。它甚至功能(如許多asp.net網站)。如果你想做更復雜的事情或想提高可訪問性,除了明確地從CSS和Javascript分離HTML之外沒有別的辦法。

單獨使用Javascript還使您的代碼更易於維護,因爲您無需讓客戶端前端開發人員混淆您的PHP代碼,反之亦然。

使用Javascript的最佳方式是首先讓php生成您的html,然後在該頁面的底部包含您的JavaScript文件並使用onDomReady等功能。這也不會強迫你僅僅因爲你的框架使用它作爲其生成的Javascript的基礎而使用特定的庫。

+2

我同意,如果該網站依賴於JavaScript,但沒有任何問題產生的js如果是從HTML代碼中分離。如果要生成特定於當前用戶的變量(如首選項),它可能非常方便。 – roborourke 2009-02-15 01:39:41

1

我個人喜歡寫我自己的Javascript,所以我並不真的希望它爲我寫,但我不認爲它是特別'危險'或'有害'的框架,爲你做,作爲只要正確完成就行。我最大的問題是,只要你想要一個功能的標準行爲,他們中的大多數都會工作,但只要你想要一些不同的東西來更好地滿足你的項目需求,就需要做很多工作來定製它,你會最好自己做。至少那是我使用CakePHP的javascript自動化的經驗。

2

這是一個相當主觀的問題,但個人而言,我不希望後端框架爲我做這件事。最好在業務邏輯,演示文稿和客戶端UI行爲之間保持一個清晰的分離,原因如下:

  • 更易維護的應用程序。
  • 更容易測試各個組件。
  • 更容易協作。不同的技能可以在不同的領域工作。
  • 應該有助於確保您的應用程序不會依賴最終用戶環境中的JavaScript。
0

我相信你應該保持語言分開。儘管它們可以相互補充。通過這種方式,您可以選擇實施該語言並創建適合您的完美組合。

1

我在CakePHP中使用Javascript和Ajax幫助程序的經驗非常積極。

他們允許服務器端開發人員進行原型和構建功能,否則這些功能需要有真正的客戶端體驗的人來完成,所有這些都不必擔心他們編寫的代碼的質量,真正的前端工程師可以專注於高級客戶端功能。

2

個人而言,我喜歡用手寫我的Javascript,不顯眼,這樣我只需要添加一個額外的事件到document.domReady中,例如正確的參數。那個小小的觸發功能就可以讓球滾動。

最好的一天做法:

保持前端代碼和後端代碼 解開,就像你可以

1

這不是爲PHP生成的Javascript是一個好主意。我建議出口的唯一JavaScript是簡單的JSON分配如下所示:

<script type="text/javascript"><!-- 
    var MyNamespace.info = <?php echo json_encode($info_array) ?> 
// --></script> 

這是消毒PHP的信息,讓它可以在客戶端上的JavaScript訪問的最簡單的方法。但是,其他任何內容都應該寫在實際的JavaScript文件中,這些文件是用文檔頭部的標籤引用的。從服務器端文件中唯一可以看出的Javascript的其他外觀,我想說的是,它是放在「onclick」和其他這樣的屬性中的東西。

這樣做的基本原理是Javascript應該由知道Javascript的前端人員編寫和維護,並且該網站應該能夠在沒有JavaScript的情況下工作(至少部分)。沒有理由在內聯中生成意大利麪條JavaScript。

查看我的PHP框架,PHP的餡餅(http://phponpie.com),瞭解如何正確實施這個示例。它保持JS和PHP分開,除了如上所示導出JSON時。但是它也提供了通過AJAX在客戶端和服務器之間輕鬆實現互操作的約定。

+0

我同意。只需注意jQuery可以很容易地在JavaScript端添加各種事件處理程序,我發現它具有比PHP方式更好的格式。 – tloach 2010-12-07 16:39:39

2

我會說這取決於什麼。擁有「智能」服務器端小部件肯定有一定的價值。例如,一個「知道」如何通過AJAX進行自我更新的小部件,或者可以處理客戶端和服務器端驗證的表單。後者就是一個例子,它會花費大量時間和成本,並且很容易在客戶端重寫無聊的驗證代碼。它不需要火箭科學的JavaScript,所以只要你的框架能夠不顯眼地處理它,我實際上建議這條路線。 此外,處理GUI內容的框架代碼(內聯或類似的東西)也不是一個壞主意。

但是,任何比這更復雜的事情,請使用Javascript本身。

0

我認爲肯定有生成JavaScript的地方。 (1)

數的一個原因產生的JavaScript是便於維修。任何依賴關係都是從框架(PHP,ruby,scala,python)自身進行顯式編碼和配置的。例如,如果您移動資產或更改上傳目錄,只需更新配置並觀看Just Work即可。

需要客戶端輸入驗證採取一些負載了你的服務器? (2)讓框架生成直接從您的數據模型中爲您導出的正確驗證代碼。通過生成的javascripted羣體,您的框架可以從緩存中爲預渲染的靜態HTML表單提供服務。如果你的表單包含大量的選擇和選項,這可能是一個巨大的勝利。

1)假設客戶已經決定,它的確定爲網站依賴(或多或少)的JavaScript上的,以及所有需要的注意事項。優雅的退化可能或不可能或不可取。

2)你需要服務器端端驗證過,但你知道,對不對?