Drupal模块的最佳应用程序工作流程隐喻是什么？
在 PHP框架中,我们认为MVC风格.我们如何看待Drupal？
在 PHP框架中,我们认为MVC风格.我们如何看待Drupal？
Asumming我正在写一些面向用户的模块,如商店,目录或论坛.
据我所知,没有或几个基于MVC的模块.
我应该将Drupal模块(作为子应用程序)一般处理为多个
屏幕通过表单和超链接连接,或者有更好的方法.
我的问题可能有点投机,但我希望有人会分享我的
意图思考模型,而不仅仅是“脚本”.
解决方法
Presentation-abstraction-control(PAC)似乎是描述Drupals一般方法的模式的最接近的匹配,但我猜这是或多或少是偶然的;)
(或多或少)独立的PAC三元组的分级组织可以粗略地映射到Drupal模块,这些模块或多或少是在共同屋顶下的独立代理,在所有三个方面(视图,控制器,模型/抽象)中进行工作.
Model-view-presenter还定义了在Drupal中可以找到的一些方面,特别是与MVC的偏差,因为View不直接从模型中获取其内容,而是从控制器中获取信息流,因此信息流是严格的.主持人<>模型.
但是,Drupal中的关注点分离是非常非正式的,并且很大程度上取决于开发人员的编码规则,因此不断在完全崩溃的边缘(有许多模块将大量逻辑放入主题层,所以或多或少地进入视野).
也就是说,不执行分离严格地似乎是Drupals成功的原因之一,因为它允许广泛的背景差异很大的人贡献,而无需受过培训的开发人员.例如,一个具有一点PHP知识的HTML / CSS Guy可以在他的模板内部实现相当多的调整和添加功能,而无需实现完整的模块.如果他做的是普遍的兴趣,它会迟早演变成一个更正式的结构/模块由其他人拾起. wannabee,业余爱好和初学者开发人员也是如此,即使没有真正了解发生了什么,他们也可以完成自己的目标,所以他们的功能想法可以被添加到贡献中,如果他们符合普遍兴趣,可以进行改进.
到目前为止,这一切都相当不错 – Drupal的核心在每个主要版本中都有更正式的(或更少的脚本),同时仍然保持添加的灵活性 – 让我们看看这将在以后持续吗？
