Drupal模块内部工作的比喻 [英] A metaphor for Drupal module's inner workings
问题描述
在PHP框架中，我们认为MVC风格。我们如何看待Drupal？
Asumming我正在编写一些面向用户的模块，如商店，目录或论坛。
据我所知，没有或几个基于MVC的模块。
我应该将Drupal模块（作为子应用程序）视为通过表单和超链接连接的
屏幕，或者有更好的方法。
我的问题可能有点推测，但我希望有人会分享我的
意图来思考模型，而不仅仅是脚本。
演示抽象控制（PAC）似乎作为描述Drupals一般方法的模式的最接近的匹配，但我猜这是或多或少是偶然的;）
（或多或少）独立的PAC三元组可以粗略地映射到Drupal模块，这些模块或多或少是独立代理，在共同的屋顶下，在所有三个方面（View，Controller，Model / Abstraction）中进行工作。
模型视图呈现r 还定义了在Drupal中可以找到的一些方面，特别是与MVC的偏差，因为View不直接从模型中获取其内容，而是从控制器中获取信息流，严格来说是 View<> Model / Presenter<> Model 。
但是Drupal中的关注点分离）相当非正式，很大程度上取决于开发人员的编码规则，因此不断完全崩溃（有许多模块将大量逻辑放入主题层，或多或少地在视图中）。 p>
这就是说，不执行分离严格地似乎是Drupals成功的原因之一，因为它允许广泛的背景差异很大的人贡献，而不必受过培训的开发人员。例如，一个具有一点PHP知识的HTML / CSS Guy可以在他的模板内部实现相当多的调整和添加功能，而无需实现完整的模块。如果他所做的是普遍的兴趣，那么其他人会把它演变成更加正式的结构/模块。 wannabee，业余爱好和初学者开发人员也是如此，即使没有真正了解发生的情况，他们也可以实现自己的目标，所以他们对功能的想法可以添加到贡献中，如果他们符合普遍的兴趣，可以进行改进。
到目前为止，这一切都相当不错 - Drupal的核心在每个主要版本中都有更正式的（或更少的脚本;），同时保持添加的灵活性ons - 我们来看看这是否会在将来搁置...
What is the best application workflow metaphor for Drupal module? In PHP frameworks we think MVC-style. How do we think inside 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) seems to be the closest match of a pattern describing Drupals general approach of things, but I guess this is more or less accidental ;)
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 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.
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).
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.
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屋！
