Метафора внутренней обработки модуля Drupal

Ответ 1

Presentation-abstraction-control (PAC), похоже, является самым близким соответствием шаблону, описывающему общий подход Drupals, но я думаю, что это больше или менее случайным;)

Иерархическая организация (более или менее) независимых триплетов PAC может быть грубо сопоставлена ​​с модулями Drupal, которые являются более или менее независимыми агентами под общей крышей, выполняя свою роль во всех трех областях (View, Controller, Model/Abstraction).

Model-view-presenter также определяет некоторые аспекты, которые можно найти в Drupal, особенно отклонение от MVC в том, что View не принимает его содержимое непосредственно из Модели, но из контроллера, так что поток информации строго View<>Controller/Presenter<>Model.

Но разделение проблем в Drupal (пока еще) довольно неформальное и во многом зависит от кодирующей дисциплины разработчиков, поэтому постоянно находится на грани полного разрушения (имеется много модулей, вставляющих много логики в тематический слой, более или менее похожий на представление).

Тем не менее, не исключая строгое разделение, по-видимому, является одной из причин успеха Drupals, поскольку это позволяет широкому кругу людей с очень разным опытом вносить свой вклад, не обучая разработчиков. Например, HTML/CSS Guy с небольшим знанием PHP может получить довольно много настроек и добавленной функциональности из своих шаблонов, без необходимости реализовывать полностью модулированные модули. Если то, что он сделал, представляет общий интерес, оно рано или поздно превратится в более формальную структуру/модуль другими людьми, собирающими его. То же самое относится к разработчикам wannabee, hobby и beginner - они могут достичь своих целей, даже не понимая, что происходит, поэтому их идеи по функциональности добавляются к вкладам и могут быть уточнены, если они отвечают общему интересу.

До сих пор это работало очень хорошо - ядро ​​Drupal получило более формальный (или менее скриптовый;) с каждой крупной версией, сохраняя при этом гибкость при добавлении - давайте посмотрим, сохранится ли это в будущем...

Ответ 2

Модули в drupal лучше всего рассматривать как набор функций (реализация "крючков" drupal), которые вызывается, когда в движке происходят определенные "события". Это не строго пользовательские события, но также, например, этапы загрузки (перед загрузкой node, после загрузки node и т.д.) Или проверки (движок проверяет разрешения, вы хотите добавить некоторые?).

В действительности, перехватчики - это функции, расширяющие функциональность drupal, поэтому вы добавляете свои собственные поведения в предоставленные drupal. Затем Drupal вызовет эти крючки в соответствующее время, чтобы вы могли выполнять свои действия.

Таким образом, нет жесткого соединения с формами или страницами, и нет никакого отношения ни к чему, как к модели MVC... с версии 6, drupal не основан на объектах.

Это касается строго дрюпальной части. Ваш модуль построен поверх этого, но он может использовать любую архитектуру. Он может быть объектно-ориентированным, и он может использовать MVC или любой другой шаблон.

Ответ 3

Ключи Drupal называются Listeners, или Наблюдатели на большинстве языков OO. Хотя они технически следуют этой схеме, не ожидайте, что полирование и зрелость вы найдете в большинстве языков и сред OO. Перехваты Drupals могут быть чрезвычайно непоследовательными, ограниченными в использовании или слишком широкими в использовании.

Слушатели, крючки, являются основным архитектурным принципом обо всем в Drupal.

Ответ 4

Это вопрос высокого уровня, но у меня будет удар.

Drupal - это структура управления контентом, есть хороший обзор здесь.

Drupal басируется на каком-то объекте orineted principals. У него есть проблемы, похожие на MVC. Существует уровень абстракции базы данных, логический уровень и система theming.

При программировании модуля drupal часто рекомендуется использовать один или несколько hooks. Это позволит вам плотно интегрировать ваш код в систему drupal. В core есть много функций, которые вы можете использовать в своих модулях. Используя их, вы уменьшите код, который вы должны написать, а также сделайте свой код более drupalish.