MVC в Joomla: как запрос превращается в страницу

В Joomla 5.x один и тот же компонент может показать список материалов на сайте, открыть форму в админке и обработать сохранение данных — потому что запрос проходит через несколько уровней MVC. Ошибка в одном из них даёт знакомые симптомы: пустой экран, неправильный шаблон, 404 или контроллер, который не видит модель. Ниже — разбор внутреннего маршрута компонента, а не универсальная лекция о паттерне.

Что именно Joomla называет MVC

В Joomla MVC живёт прежде всего внутри компонента. Компонент получает запрос, выбирает контроллер, контроллер запускает действие, модель работает с данными, а представление готовит результат для шаблона. Модуль и плагин могут участвовать в той же странице, но они не заменяют MVC-слой компонента.

В Joomla MVC не отвечает на вопрос «где находится весь код страницы». Он отвечает на другой вопрос: какой слой должен принять решение, получить данные и превратить их в конкретный формат ответа.

Компонент — расширение, которое получает основной участок страницы Joomla. Например, компонент материалов отвечает за содержимое статьи, а компонент пользователей — за соответствующие экраны сайта и панели управления.

Путь запроса: от URL до шаблона

Для примера возьмём условный компонент com_example в Joomla 5.x и запрос к представлению items. Точный URL зависит от маршрутизации и настроек меню, но внутри компонента последовательность остаётся примерно такой.

1. Joomla загружает приложение. Система определяет, работает ли запрос в публичной части или в админке, загружает конфигурацию, пользователей, языки и зарегистрированные расширения.
2. Выбирается компонент. Параметр компонента и пункт меню приводят Joomla к расширению вроде com_example. Компонент получает основной участок ответа, тогда как модули обычно добавляют боковые или вспомогательные блоки.
3. Диспетчер компонента передаёт запрос дальше. В Joomla 4.x и 5.x современный компонент обычно описывает сервисы в services/provider.php. Через этот слой Joomla получает фабрику MVC и диспетчер компонента, а не подключает один большой файл вручную.
4. Контроллер определяет действие. Для обычного отображения используется базовый контроллер отображения. Для операций вроде сохранения или удаления вызывается конкретный task-контроллер. Контроллер должен проверить допустимость операции, права доступа и CSRF-токен там, где действие меняет состояние.
5. Создаётся модель. Контроллер или представление получает модель через MVC-фабрику компонента. Для списка это обычно модель на базе списка Joomla, для одной записи — модель с логикой загрузки и сохранения конкретной сущности.
6. Модель читает данные. Она принимает фильтры, сортировку и пагинацию, строит запрос к базе и возвращает данные. Если SQL спрятан в шаблоне, граница MVC уже нарушена: такой код труднее тестировать, кэшировать и переносить.
7. Представление выбирает шаблон. Представление подготавливает модель, состояние фильтров и дополнительные данные, затем Joomla ищет шаблон вроде tmpl/items/default.php. Имя формата важно: HTML, RSS и JSON могут использовать разные представления или layout-файлы.
8. Шаблон формирует ответ. В шаблоне должен находиться вывод: заголовки, ссылки, поля формы и проверка наличия значения для отображения. После этого результат возвращается компоненту и встраивается в общий шаблон сайта.

Как устроен компонент в Joomla 5.x

Современный компонент не сводится к папке с контроллером и файлу view.html.php. Минимальная структура обычно включает сервисный провайдер, класс расширения, пространства имён и отдельные каталоги для сайта и админки. Названия могут отличаться, но роли остаются теми же.

administrator/components/com_example/
├── services/
│   └── provider.php
├── src/
│   ├── Controller/
│   │   └── DisplayController.php
│   ├── Extension/
│   │   └── ExampleComponent.php
│   ├── Model/
│   │   └── ItemsModel.php
│   └── View/
│       └── Items/
│           └── HtmlView.php
└── tmpl/
    └── items/
        └── default.php

components/com_example/
├── src/
├── tmpl/
└── services/

Этот скелет не является готовым компонентом: ему нужны манифест, пространства имён, регистрация сервисов, языковые файлы и права доступа. Но он показывает важную границу. Код админки и код публичной части могут находиться в разных каталогах и иметь разные контроллеры, представления и шаблоны, хотя работают с одной предметной областью.

Зачем нужен services/provider.php

В Joomla 4.x и 5.x расширения используют контейнер зависимостей. Сервисный провайдер регистрирует фабрику MVC, диспетчер, маршрутизатор и другие зависимости компонента. Благодаря этому контроллер не обязан вручную создавать модель через длинную цепочку конструкторов.

Практический эффект заметен при расширении компонента: заменяется или настраивается сервис, а не переписывается каждый вызов. Ошибка в провайдере при этом проявляется раньше MVC-логики — компонент может не загрузиться ещё до запуска контроллера.

Почему пространства имён важнее старой структуры

В старых версиях Joomla разработчики часто подключали классы через файлы с именами вроде controller.php и model.php. В Joomla 4.x и 5.x основной путь — классы с пространствами имён и автозагрузкой PSR-4. Поэтому класс из src/Model/ItemsModel.php должен соответствовать зарегистрированному пространству имён и имени класса. Похожее имя файла само по себе класс не подключит.

Где MVC ломается первым

Ошибки в Joomla часто выглядят одинаково, хотя происходят на разных уровнях. Сначала определите, дошёл ли запрос до компонента, затем проверяйте модель и только после этого шаблон.

• 404 вместо страницы. Проверьте пункт меню, имя компонента, view и маршрутизацию. SEF-адрес не всегда показывает внутреннее имя представления.
• Класс не найден. Сверьте пространство имён, регистр букв, путь внутри src и автозагрузку. На Linux регистр имени файла имеет значение.
• Шаблон не видит переменную. Модель могла вернуть пустой результат, а представление — не передать данные в layout. Проверяйте цепочку «запрос — модель — представление — шаблон», а не добавляйте SQL в шаблон.
• Форма открывается, но не сохраняет данные. Проверьте task, HTTP-метод, CSRF-токен, права доступа и обработчик сохранения. Вывод формы и её обработка — разные действия контроллера.
• В админке работает, на сайте нет. Это часто означает, что публичная и административная части используют разные namespaces, пути, ACL-правила или сервисы. Копирование файла из administrator в components проблему не решает.

Граничные случаи и цена неправильного слоя

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

Контроллер тоже не должен становиться местом для всей бизнес-логики. Если одна и та же операция запускается из API, консольной команды и веб-формы, её лучше вынести в отдельный сервис компонента. Иначе исправление в одном контроллере не попадёт в другие точки входа.

Шаблон переопределения может изменить HTML без правки компонента, но не меняет его модель и правила доступа. Это критичная граница для владельцев сайта: визуальное переопределение не должно использоваться как способ исправить неверную выборку или защитить административное действие.

Что проверять при отладке

• какой компонент и view реально выбраны для запроса;
• какой task передан контроллеру;
• какая модель создана фабрикой и какие фильтры попали в её состояние;
• какой SQL и время выполнения видны в профилировщике на тестовой копии;
• какой layout загрузился и не переопределён ли он шаблоном сайта.

У Joomla нет универсальной цифры, после которой MVC-компонент считается медленным. Замеряйте время запроса, число SQL-запросов, размер результата и время рендеринга отдельно. Иначе оптимизация может лечить шаблон, хотя задержка находится в базе.

Что делать дальше

Возьмите один существующий компонент Joomla 5.x и нарисуйте его цепочку: URL или пункт меню, диспетчер, контроллер, модель, view и layout. Затем найдите место, где формируется запрос к базе, и отдельно проверьте права на чтение и изменение данных. Такой разбор быстрее показывает реальную архитектуру проекта, чем чтение всех файлов подряд.

После этого смотрите в проде на время SQL-запросов и количество запросов на страницу. Если компонент часто выводит один и тот же список, отдельной темой станет кэширование: оно меняет жизненный цикл данных, но не отменяет разделение на контроллер, модель и представление.

Термин: layout — отдельный файл шаблона, который рисует конкретный фрагмент представления. Он может быть переопределён в шаблоне сайта без изменения исходных файлов компонента.