Drupal模塊的最佳應用工作流隱喻是什麼？ 在PHP框架中，我們認爲MVC風格。我們如何看待Drupal？Drupal模塊內部工作的隱喻
Asumming我在寫一些面向用戶的模塊，如Shop，Catalog或Forum。 據我瞭解，沒有或很少的MVC模塊。 我通常應該將Drupal模塊（作爲子應用程序）當作通過表單和超鏈接連接的多個 屏幕，或者有更好的方法。
我的問題可能有點推測，但我希望有人會分享我的思維模型，而不僅僅是「腳本」。
Presentation-abstraction-control（PAC）似乎是描述的事情Drupals一般方法的模式最接近的比賽，但我想這或多或少是偶然的;）
的分層組織（或多或少）獨立PAC三元組可以粗略地映射到Drupal模塊，它們或多或少都是獨立的代理，在三個領域（視圖，控制器，模型/抽象）中發揮作用。
Model-view-presenter還定義了一些方面，可以在Drupal被發現，尤其是在該視圖不直接從示範利用其內容從MVC的偏差，但是從控制器，從而使信息的流動是嚴格View<>Controller/Presenter<>Model。
但是，Drupal中關注點的分離（截至目前）非常不正式，並且很大程度上取決於開發人員的編碼規則，因此始終處於完全崩潰的邊緣（有許多模塊將大量邏輯進入主題層，或多或少地進入視圖）。
也就是說，不執行分離嚴格似乎是原因Drupals成功的一個，因爲它允許各種各樣的人非常不同的背景，而無需進行培訓，開發者貢獻。例如，PHP的知識缺乏的HTML/CSS蓋伊從他個人的模板內實現相當大量的調整和補充功能，而無需實現完全成熟的模塊。如果他的所作所爲是普遍關心的，它遲早會演變成其他人拿起它一個更正式的結構/模塊。對於喜歡玩遊戲的人，興趣愛好者和初學者開發者來說也是如此 - 即使他們沒有真正理解正在發生的事情，他們也可以完成他們的目標，所以他們的功能理念可以被添加到貢獻中，並且可以被完善，只要他們符合一般興趣。
到目前爲止，這工作得很好 - Drupal的核心得到了更正規的;與每一個主要版本，同時仍保持對附加功能的靈活性 - 讓我們來看看這是否會在未來撐起（以下scriptish） ...
在drupal中的模塊被認爲是一個函數集合（實現drupal的「鉤子」），當引擎中發生某些「事件」時被調用。這些不是嚴格的用戶事件，而且還有，例如，加載階段（加載節點之前，加載節點之後等）或檢查（引擎正在檢查權限，是否要添加一些？ ）。
實際上，鉤子是擴展drupal功能的函數，因此您可以將自己的行爲添加到drupal提供的行爲中。然後Drupal會在適當的時間調用這些鉤子，以便您執行您的操作。
因此，與表單或頁面沒有緊密聯繫，並且與MVC模型沒有任何關係......從版本6開始，drupal不是基於對象的。
這是嚴格的drupal部分。你的模塊建立在此之上，但它可以使用任何你想要的架構。它可能是面向對象的，它可能使用MVC或任何其他模式。
這是一個高水平的問題，但我會刺。
Drupal是一個內容管理框架，有一個很好的概述here.
Drupal是一些object orineted principals bassed。它與MVC非常類似，關注點很多。有一個database abstraction layer，一個邏輯層和theming system。
當編程一個drupal模塊時，通常建議使用一個或多個可用的hooks。這將使您可以將代碼緊密集成到Drupal系統中。 core內置了很多功能，您可以在模塊中使用這些功能。利用這些將減少您必須編寫的代碼，並使代碼更加小心翼翼。
Drupal的掛鉤被稱爲偵聽器，或者在大多數OO語言Observers。 雖然他們在技術上folluw這種模式，不要指望polishedness和成熟，你會在大多數面嚮對象語言和環境的發現。 Drupals掛鉤可能極不一致，使用受限或使用範圍太廣。
聽衆，鉤，大約在Drupal一切的核心架構原則。
然後Drupal應用程序聽起來更像基於事件的應用程序，作爲一般類別。 – AlexA 2009-08-24 10:25:07