Drupal 模块内部工作的比喻 [英] A metaphor for Drupal module's inner workings

问题描述

Drupal 模块的最佳应用程序工作流比喻是什么?在 PHP 框架中，我们认为 MVC 风格.我们如何在 Drupal 内部思考?

What is the best application workflow metaphor for Drupal module? In PHP frameworks we think MVC-style. How do we think inside Drupal?

假设我正在编写一些面向用户的模块，例如商店、目录或论坛.据我所知，没有或很少有基于 MVC 的模块.我是否应该将 Drupal 模块(作为子应用程序)视为许多通过表单和超链接连接的屏幕或有更好的方法.

Asumming I am writing some user-oriented module like Shop, Catalog or Forum. As far as I understand there are no or few MVC based modules. Should I generally treat Drupal modules (as sub-application) as a number of screens connected via forms and hyperlinks or there is a better way.

我的问题可能有点推测，但我希望有人能分享我的意图思考模型，而不仅仅是脚本".

My question may be a little bit speculative, but I hope someone will share my intent to think models, not just "scripts".

推荐答案

Presentation-abstraction-control (PAC) 似乎是描述 Drupals 一般事物方法的模式的最接近匹配，但我想这或多或少是偶然的 ;)

Presentation-abstraction-control (PAC) seems to be the closest match of a pattern describing Drupals general approach of things, but I guess this is more or less accidental ;)

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

The hierarchical organization of (more or less) independent PAC triplets can be roughly mapped to Drupal modules being more or less independent agents under a common roof, doing their part in all three areas (View, Controller, Model/Abstraction).

Model-view-presenter 还定义了一些可以在 Drupal 中找到的方面，尤其是与 MVC 的不同之处在于 View 不直接从模型中获取其内容，而是从控制器中获取内容，因此信息流是严格的View<>Controller/Presenter<>Model.

Model-view-presenter also defines some aspects that can be found in Drupal, especially the deviation from MVC in that the View does not take its contents directly from the Model, but from the controller, so that the flow of information is strictly View<>Controller/Presenter<>Model.

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

But the separation of concerns in Drupal is (as of yet) quite informal and depends a lot on the coding discipline of the developers, therefore being constantly on the edge of breaking down completely (there are many modules putting plenty of logic into the theming layer, so more or less into the view).

也就是说，不严格执行分离似乎是 Drupals 成功的原因之一，因为它允许具有不同背景的广泛人群做出贡献，而无需经过培训的开发人员.例如，一个对 PHP 有一点了解的 HTML/CSS 专家可以仅从他的模板中完成大量调整和添加功能，而无需实现完整的模块.如果他所做的事情具有普遍意义，那么它迟早会演变成为其他人接受的更正式的结构/模块.对追求者、业余爱好者和初学者开发者也是如此——即使他们没有真正了解正在发生的事情，他们也可以实现他们的目标，因此他们对功能的想法会被添加到贡献中，并且如果他们满足普遍兴趣，则可以改进.

That said, not enforcing the separation to strictly seems to be one of the reasons for Drupals success, as it allows a wide range of people with very different backgrounds to contribute without having to be trained developers. For example, a HTML/CSS Guy with a little knowledge of PHP can achieve quite a lot of tweaking and added functionality from within his templates alone, without having to implement full blown modules. If what he did is of general interest, it will sooner or later evolve into a more formal structure/module by other people picking it up. Same goes for the wannabee, hobby and beginner developers - they can accomplish their goals even without really understanding whats going on, so their ideas for functionalities get added to the contributions and can be refined, if they meet a general interest.

到目前为止，这运行得非常好 - Drupal 的核心在每个主要版本中变得更加正式(或更少脚本 ;)同时仍然保持附加组件的灵活性 - 让我们看看这是否会成立未来...

So far this has worked pretty well - the core of Drupal got more formal (or less scriptish ;) with every major release while still keeping the flexibility for add ons - let's see if this will hold up in the future ...

这篇关于Drupal 模块内部工作的比喻的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！