Привет, друзья! У меня отличная новость — я уезжаю в отпуск.

В рамках программы импортозамещения и ответных санкций, в этом году мы летим в Крым, гостить в городе-герой Севастополь.

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

Неожиданно выяснилось, что я обещал написать о работе контроллеров через Ajax, но забыл:

Позже мы научим наши контроллеры обрабатывать запросы и выдавать ответы через Ajax.

Так что пишу еще один, самый-самый последний урок из курса =)

Общие принципы работы через Ajax заключаются в том, что

• javascript посылает запрос на сервер, используя метод XMLHttpRequest

• Контроллер определяет, что запросы был сделан через ajax и отвечать нужно в определённом формате — мы любим JSON

• При успехе или ошибке на фронтенд всегда возвращается массив с данными установленного формата

• В зависимости от ответа, javascript что-то делает со страницей

Чтобы детально разобраться в работе через ajax, мы сделаем на нашем сайте ajax-пагинацию, используя контроллер News. Нетерпеливые читатели могут сразу посмотреть на результат.

На выходных я столкнулся с неприятным поведением сотового оператора Мегафон, услугами которого пользуюсь уже почти 10 лет. Дело в том, что, прокатившись из Кемерово в Новосибирск на 2 дня, я заплатил 500 рублей за 50 мегабайт мобильного интернета.

Распечатка списаний показала, что на моём тарифе «Всё включено», где предоплачено 3 Gb трафика, 50 мегабайт в Новосибирской области списали за дополнительную плату. Я не первый раз езжу в соседний областной центр в гости к родственникам, но никогда такого не было — ибо это один сибирский регион.

Покопавшись на сайте, я нашел раздел с роумингом и цифры совпали.

Некоторое время назад взяла и сломалась любимая Sony PS4. Это прекрасный чудо-прибор, подаривший огромное количество приятных часов отдыха и удовольствия, вдруг стал выключаться сам по себе, вопреки моему желанию. То есть, включаешь консоль, а она берёт и выключается через 2-3 минуты.

Делать нечего, звоню в местный сервис, благо до окончания гарантии еще 3 недели, где меня натурально шокируют — в Кемерово нет сервиса для PS4.

Более того, во всей огромной Российской Федерации ровно один сервисный центр для консолей Sony, который располагается в Москве, так что нужно звонить в техподдержку по номеру 8 800 200 7667.

Это последнее занятие нашего курса, в котором мы закрепим знания по работе с Composer и чужими классами, добавлением постраничной навигации разделу новостей.

Первым делом выбираем что-нибудь попроще на https://packagist.org/search/?q=pagination - мне приглянулся второй пункт, с kilte/pagination. Добавляем его в наш composer.json и устанавливаем на сервере.

Теперь пишем новый метод в Brevis\Controller:

    /**
     * Возвращает массив с постраничной навигацией
     *
     * @param $totalItems
     * @param int $currentPage
     * @param int $itemsPerPage
     * @param int $neighbours
     *
     * @return array
     */
    public function getPagination($totalItems, $currentPage = 1, $itemsPerPage = 10, $neighbours = 2) {
        $pagination = new Pagination($totalItems, $currentPage, $itemsPerPage, $neighbours);

        return $pagination->build();
    }

А в начале файла указываем

use \Kilte\Pagination\Pagination as Pagination;

Всё, в нашем проекте уже есть постраничная навигация.

Дальше мы научим контроллер новостей её использовать, а шаблон - оформлять.

На прошлом занятии мы подключили xPDO и попробовали его в работе. Сегодня мы можем добавим в БД пару новостей и вывести их на отдельных страницах.

Для этого нам нужно будет научить контроллер News определять, что именно запросил пользователь: список новостей или отдельную новость. Это несложно, нужно только проверять, что указано в url после /news/.

Пишем контроллер Brevis\Controllers\News с вот такой инициализацией:

    public function initialize(array $params = array()) {
        if (empty($params)) {
            $this->redirect("/{$this->name}/");
        }
        elseif (!empty($params[0])) {
            $c = $this->core->xpdo->newQuery('Brevis\Model\News');
            if (is_numeric($params[0])) {
                $c->where(array('id' => $params[0]));
            }
            else {
                $c->where(array('alias' => $params[0]));
            }
            if ($news = $this->core->xpdo->getObject('Brevis\Model\News', $c)) {
                $alias = $news->get('alias');
                if (isset($params[1]) || $params[0] != $alias) {
                    $this->redirect("/{$this->name}/{$alias}");
                }
                else {
                    $this->item = $news;
                }
            }
            else {
                $this->redirect("/{$this->name}/");
            }
        }

        return true;
    }

Давайте разберёмся, что здесь происходит?

На прошлом занятии мы освоили Composer, переместили Fenom в зависимости, и переписали наш проект для поддержки автозагрузки стандарта PSR-4.

А сегодня мы добавим в проект xPDO, напишем схему, сгенерируем модель, создадим таблицу и выведем новости на сайте.Для этого нам придётся внести много изменений в код проекта.

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

Но, сначала мы меняем наш composer.json:

{
  "name": "Brevis",
  "autoload": {
    "psr-4": {
      "Brevis\\": "core/"
    }
  },
  "require": {
    "php": ">=5.3.0",
    "fenom/fenom": "2.*",
    "xpdo/xpdo": "3.0.*@dev"
  },
  "scripts": {
    "post-install-cmd": "\\Brevis\\Core::cleanPackages",
    "post-update-cmd": "\\Brevis\\Core::cleanPackages"
  }
}

В блоке scripts я добавил вызов нового метода для очистки ненужные директорий устанавливаемых пакетов (тесты, примеры, документация и т.п.). Они только замедляют синхронизацию проекта с удалённым сервером.

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

А именно — начать использовать менеджер зависимостей для PHP — Composer. Он позволит нам легко устанавливать разные полезные вещи на сайт, обновлять их и даже удалять. Если вы уже работали с менеджером пакетов GNU/Linux — то вам всё это будет очень знакомо.

В качестве разминки, удалим Fenom из директории core и установим через Composer. Для этого нужно в корне сайта создать файл composer.json и прописать в нём требуемые пакеты (подробнее можно прочитать на Хабре):

{
    "require": {
        "php":">=5.3.0",
        "fenom/fenom": "2.*"
    }
}

Теперь нужно только скачать composer.phar и запустить его в корне сайта:

php composer.phar install

На modhost.pro и качать ничего не нужно — просто запускаем composer в директории:

composer install

И волшебным образом у нас появляется директория /vendor/ с установленным Fenom. Что же с ним делать дальше?

На прошлом занятии мы подключили шаблонизатор Fenom к нашей системе и написали простенький шаблон.

Теперь пришло время написать уже нормальные шаблоны для страниц Home и Test, при этом они будут наследовать один общий шаблон Base, в котором будет генерироваться меню сайта.

В принципе, основная часть сайта после этого будет закончена и нужно будет только наращивать функционал — писать тексты, выводить их в шаблонах с разбивкой на страницы и прочая, привычная по MODX работа.

Поэтому, в конце урока вам предлагается выбрать, как именно мы будем работать дальше. На всякий случай, вот как должен выглядеть наш сайт после этого урока — s1889.bez.modhost.pro.

Знаю-знаю, мы собирались работать на чистом PHP, безо всяких фреймворков, но о шаблонизаторах речи не было!

Если серьёзно, то я по всякому прикинул, как заставить наш простенький сайт выводить HTML, и не вписывать его в PHP, а хранить в шаблонах.

Варианта ровно два: написать собственный жуткий глючный велосипед, который будет читать шаблон и заменять в нём плейсхолдеры на значения через str_replace(), или подключить нормальный шаблонизатор.

Так как мы все тут от MODX люди не очень далёкие, так почему бы не освоить работу с Fenom, который в нём с некоторых пор доступен? Думаю, возражений не будет, так что поехали!

На прошлом занятии мы набросали основу нашего ядра, а сегодня нам предстоит воспользоваться преимуществами ООП и написать базовый контроллер, от которого будут наследоваться все остальные.

Зачем это нужно? Да, хотя бы, затем, чтобы не прописывать одни и те же методы в каждом контроллере. Написать один общий, а потом менять только нужные части. Это гораздо правильнее и удобнее.

К тому же, чем меньше дублируется кода, тем больше гарантий, что этот код работает всегда одинаково. Отсюда следует простой вывод, что дублирования кода быть вообще не должно.

Если вы в двух местах пишете один и тот же метод — у вас проблема с логикой работы приложения.

Итак, приступаем.

На этом занятии мы начнём писать ядро нашего сайта и заложим основу для работы контроллеров страниц.

Ядро - это один основной класс, с общими для всех контроллеров методами. А контроллеры - это другие php классы, которые будут отвечать за функционал какого-то раздела сайта.

Контроллеры будут лежать в специальной директории, откуда их запустит основной класс. Запрос приходит на index.php, тот инициализирует основной класс и просит обработать запрос. Ядро определяет, к какому разделу сайта обращён запрос и загружает его контроллер, передавая ему все полномочия на генерацию ответа.

Дальше контроллер проверит параметры запроса и выдаст результат, или редирект на страницу с ошибкой. Позже мы научим наши контроллеры обрабатывать запросы и выдавать ответы через Ajax.

Логическая цепочка выходит такая: index.php -> Сore -> Controllers_Page.