Drupal模块内部工作的隐喻

Question

Drupal模块的最佳应用程序工作流隐喻是什么？ 在PHP框架中我们认为MVC风格。我们如何思考Drupal？

Asumming我正在编写一些面向用户的模块，如商店，目录或论坛。 据我所知，没有或几个基于MVC的模块。 我是否应该将Drupal模块（作为子应用程序）作为一些来处理 屏幕通过表格和超链接连接或有更好的方式。

我的问题可能有点推测，但我希望有人会分享我的 意图思考模型，而不只是“脚本”。

Answer 1

Presentation-abstraction-control（PAC）似乎是描述Drupals一般方法的模式中最接近的匹配，但我猜这或多或少是偶然的;）

（或多或少）独立PAC三元组的层次结构可以粗略地映射到Drupal模块，它们在一个共同的屋檐下或多或少是独立的代理，在所有三个领域（视图，控制器，模型/抽象）中发挥作用。

Model-view-presenter还定义了可以在Drupal中找到的一些方面，特别是与MVC的偏差，因为View不直接从Model中获取其内容，而是从控制器中获取，因此信息流是严格View<>Controller/Presenter<>Model。

但是，Drupal中关注点的分离是（非常）非常非正式的，并且很大程度上取决于开发人员的编码规则，因此总是处于完全崩溃的边缘（有许多模块将大量逻辑放入主题层，或多或少地进入视图）。

也就是说，严格执行分离似乎并不是Drupals成功的原因之一，因为它允许各种背景不同的人在不必接受培训的开发人员的情况下做出贡献。例如，一个对PHP有一点了解的HTML / CSS Guy可以在他的模板中实现相当多的调整和添加功能，而无需实现完整的模块。如果他所做的事情具有普遍意义，那么其他人捡起它会迟早会将演变成一个更正式的结构/模块。对于崇拜者，爱好者和初学者开发者来说也是如此 - 他们甚至可以在不了解最新情况的情况下实现他们的目标，因此他们对功能的想法会被添加到贡献中，并且如果他们满足一般兴趣，可以进行改进。

到目前为止，这已经运行得很好 - Drupal的核心在每个主要版本中都有更正式（或更少 scriptish ;），同时仍保持添加的灵活性 - 让我们看看这是否会成功在未来...

Answer 2

drupal中的模块最好被认为是函数的集合（drupal的“钩子”的实现），当引擎中发生某些“事件”时会调用它们。这些不是严格的用户事件，但也有，例如，加载阶段（加载节点之前，加载节点之后等等），或检查（引擎正在检查权限，你想添加一些吗？） ）。

实际上，钩子是扩展drupal功能的函数，所以你将自己的行为添加到drupal提供的行为中。然后，Drupal会在适当的时间调用这些挂钩，以便您执行操作。

因此没有与表单或页面的紧密联系，并且与MVC模型之间没有任何关系......从版本6开始，drupal不是基于对象的。

这是严格的drupal部分。您的模块是基于此构建的，但它可以使用您希望的任何架构。它可能是面向对象的，它可能使用MVC或任何其他模式。

Answer 3

Drupal挂钩在大多数OO语言中称为监听器或Observers。 虽然他们在技术上遵循这种模式，但不要指望在大多数面向对象语言和环境中都会找到优雅和成熟度。 Drupals挂钩可能非常不一致，使用受限或使用范围太广。

监听器，钩子，是关于Drupal中所有内容的核心架构原则。

Answer 4

这是一个高级别的问题，但我会有一个问题。

Drupal是一个内容管理框架，有一个很好的概述here.

Drupal基于一些object orineted principals。它有一些关注点，就像MVC一样。有一个database abstraction layer，一个逻辑图层和theming system。

编程drupal模块时，通常建议使用一个或多个hooks可用。这将允许您将代码紧密集成到drupal系统中。 core内置了许多功能，您可以在模块中使用这些功能。利用这些将减少您必须编写的代码，并使您的代码更加笨拙。