В данной статье рассматривается принцип модульности друпала на живых примерах. Список модулей, которые затрагиваются в статье:

* Таксономия
* ImageCache
* PathAuto
* Book
* Модульность друпала

**fatalerror** написал:

> весьма внимательно слежу за jSeblod CCK у Joomla

Если-бы среди принципиальных различий между друпой и Joomla был-бы только CCK, это было-бы слишком просто. На самом деле подход CCK в друпале применяется в большинстве других "жизненно-важных" пластах CMS. Например взять модули такономия, imageCache и pathauto.

## Таксономия

Пожалуй этому модулю подчиняется любой модуль, отвечающий за создание контента. Одиночный, множественный выбор или тэги (или их комбинацию) - можно наложить на любой тип контента. При создании нового типа контента - на странице настроек модуля таксономии появляется новая галочка, потому что за таксономию отвечает модуль таксономии! Это было сложно понять и принять в друпале, но по началу много раз искал эту галочку именно на странице настроек типа контента.

## ImageCache

В друпале один модуль решает одну очень узкую задачу. При этом он предоставляет набор функций, которые могут задействовать другие модули, чтобы воспользоваться его функционалом (связыванием модулей занимается ядро). Таким образом, мне достаточно один раз установить ImageCache (обработка изображений) для того чтобы все модули которым необходимо как-то менять фото, могли это делать средствами этого самого ImageCache. Изменение размеров, создание эскизов, crop (кадрирование), наложение ватермарка, наложение маски - все это можно делегировать данному модулю, если ваш модуль нуждается в подобной обработке изображений. Фотогалереи; картинки в контенте, маштабированные по заданной ширине (со ссылкой на оригинал); аватарки юзеров; превьюшки списков новостей (и других типов материалов) - ImageCache как-бы проникает в модули, которым нужна обработка картинок.

## PathAuto

Данный модуль предоставляет механизм автоматического составления УРЛ-ов. Для русскоязычных сайтов он-же отвечает за транслитерацию. Прелесть друпала обнаруживается когда мы включаем модули, использующие PathAuto. Например модуль book (полезен для вики или составления документации), позволяющий систематизировать страницы сайта в иерархии (деревья документов, в терминологии этого модуля - подшивки), когда каждый родитель показывает список детей, показывает ссылки на следующую/предыдущую страницу.
Иерархия документа отображается в УРЛ-е.
УРЛ каждого документа является перечислением через слеш "/" транслитерированных УРЛ-ов родителей для этого документа (однако это поведение можно поменять подстановочными шаблонами). Как бонус вместо транслитерации родителей можно использовать англоязычный синоним русскоязычного слова (по словарю).

настройки модуля pathauto:

*(дальше идет большой список подстановочных шаблонов, которые можно комбинировать как угодно. При установке модуля токен - в подстановочных шаблонах появляются поля еще не сохраненного материала, и данные текущего пользователя - id, name и др.)*

## Book

Когда я устанавливаю модуль book - в настройках модуля pathauto появляется новое поле - для того чтобы управлять авто-генерацией ЧПУ, а в самом модуле book таких настроек нет. Эти настройки как-бы "забрал себе" модуль pathauto, потому что он на этом специализируется.

настройки модуля book:

## Модульность друпала

Если модуль в друпале интегрируется не со всеми имеющимися модулями, то по крайней мере с теми, которые нуждаются в его функциональности. И о том чтобы так было, заботится команда, компании Aquia, ну и конечно любой другой разработчик, кому это интересно.

**ksuit** написал:
> У друпала сплошные зависимости модуля от модуля.

Да, это так. А что в этом плохого?
Модульность - сильная сторона друпала.

**ksuit** написал:
> Чтобы установить некое "интересное" дополнение к друпалу приходится тащить в систему целый ворох непонятных модулей.

Здесь вы неправы. Назовите хотя-бы один модуль, который тащит за собой "ворох непонятных модулей"? Более того, действительно, зависимости есть, и иногда какой-то специфичный модуль требует установки другого, функциональность которого в чистом виде мне не нужна. На сложных проектах конечно, у меня может и найдется модуль, от которого зависит нужный мне модуль, но это нельзя назвать недостатком, поскольку написание модулей в друпале во многом опирается на код и функции других модулей. И что плохого в том чтобы установить два модуля вместо одного ради действительно сложного и очень специфичного функционала, который я сам не напишу и за месяц? Но в основном модули на 90% зависят от других реально нужных модулей, т.е. "уровень шума" в модулях очень маленький.

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