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

Какова лучшая метафора рабочего процесса приложения для модуля Drupal? В PHP-фреймворках мы думаем о MVC-стиле. Как мы думаем внутри Drupal?

Итак, я пишу какой-то ориентированный на пользователя модуль, такой как Магазин, Каталог или Форум. Насколько я понимаю, нет или мало модулей на основе MVC. Должен ли я вообще относиться к модулям Drupal (как к субприложению) как к нескольким экранам, соединенным через формы и гиперссылки, или есть лучший способ.

Мой вопрос может быть немного умозрительным, но я надеюсь, что кто-то поделится моим намерением думать о моделях, а не просто "скрипты».

Ответы на вопрос(4)

Решение Вопроса

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

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

Модель-представление-презентатор также определяет некоторые аспекты, которые могут быть найдены в Drupal, особенно отклонение от MVC в том, что View берет свое содержимое не непосредственно из модели, а из контроллера, так что поток информации строго.ViewController/PresenterModel

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

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

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

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

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

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

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

 AlexA24 авг. 2009 г., 12:25
Тогда приложение Drupal звучит больше как приложение на основе событий, как общая категория.

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

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

Drupal основан на некоторыхобъектно-ориентированные принципы, У него есть разделение проблем, очень как MVC. Eстьуровень абстракции базы данных, логический слой исистема тем.

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

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

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

Ваш ответ на вопрос