Уже достаточно давно в свободное время штудирую курс Test Driven Laravel, посвященный, очевидно, применению методики TDD (Test-Driven Development) к разработке ПО на Ларавеле.

Курс последовательно, начиная с написания самого первого теста, демонстрирует разработку приложения по продаже билетов на концерты. Хотя я еще не изучил и половины, должен сказать, потраченных 150$ совсем не жалко (а сейчас он уже 250$, распродажи рулят). Вещает автор бодро и понятно. Все примеры и приложение в целом можно найти в закрытом репозитории на гитхабе. Причем, каждый коммит эквивалентен одному уроку, так что без труда можно повторить всю эволюцию рассматриваемого в курсе кода.

Вообще, видео-уроки я не очень-то люблю, но здесь формат совсем не раздражает (хотя текстовый вариант все равно был бы еще круче). Так что — рекомендую.

Что же касается самой методики TDD, мне кажется, у нас ей немного не повезло с локализацией названия. У нас это называется «Разработка через тестирование», то есть слово driven редуцировали до нашего «через».

А что такое вообще в данном контексте «через»? Можно прыгнуть через лужу, или можно кинуть через известно что. Эти варианты тут, видимо, не очень подходят. Можно выйти через окно, или даже войти через дверь. Это уже ближе, но все еще непонятно.

При беглом ознакомлении с таким локализованным определением, понятно одно. Сначала надо написать тест, а потом код под этот тест. Ну ок, любопытная методика. А вот есть еще одна: можно сначала написать код, а потом не писать тест. Тоже прикольно, а главное — гораздо быстрее.

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

И пока не попробуешь что-нибудь сделать «через тесты» сам, не очень-то ясно, что в самой методике главное отнюдь не наличие тестов на весь код в финале. Это лишь сопутствующая плюшка, хотя конечно тоже важная. Главное заключается как раз в слове driven. В том, что написанный тобой же тест при каждом запуске говорит тебе:

• Ты хотел по этому урлу увидеть данные, а урла такого чо-то нету. Может, добавишь?
• Вижу урл, только почему-то данных не вижу. Надо что-нибудь вывести.
• Урл пытается вывести объекты, но не знает, где их взять. Давай табличку в БД создадим?

И так далее. То есть суть в том, что если грамотно (в форме теста) описать желаемый результат, то не нужно даже особо думать, что еще ты забыл сделать и почему не работает. Лог очередного запуска теста сам тебе расскажет — чего не хватает. На мой взгляд, если эту суть осознать, методика предстает совсем в другом свете, нежели «давайте потратим в два раза больше времени, чтобы у нас был вагон тестов на каждый чих».

Как-то так.

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

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

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

<ol>
    <li v-if="people" v-for="(person, index) in people">
        <autocomplete
            url="/people/search_by_name"
            anchor="name"
            label="email"
            :initValue="person.name"
            :onInput="autocompleteNameChanged"
            :onSelect="autocompleteGetData"></autocomplete>
        <button type="button" v-on:click="removePerson($event, index)" class="btn btn-default"><span class="fa fa-times"></span></button>
    </li>
</ol>

Когда делали Консерваторию, была задача сделать блок/страницу юбиляров. То есть выводить не просто людей, у которых скоро день рождения, а с круглыми значениями возраста. Заканчивающимися на 5 и 0. Сделать это чисто коробочными вьюзами не особо получается, поэтому пришлось написать немножко кода, о чем и расскажу.

Но сначала небольшое отступление. Как известно, в Drupal 8 модуль Views включили в ядро и это прекрасно. Действительно, контриб, который автоматически ставят во все проекты, не должен оставаться просто контрибом. Но некоторые вещи, сопутствующие включению/порту на D8, несколько раздражают.

Подробности далее.

Работу с AJAX в OctoberCMS я уже раньше немного затрагивал, но для бэк-энда. А теперь можно затронуть и фронт. В этой заметке мы сделаем кнопочку Load More, чтобы подгружала без перезагрузки страницы новые посты блога (из плагина RainLab.Blog).

На первый взгляд может показаться, что для этого нужно влезть в компонент Posts этого плагина, но на самом деле — вовсе не нужно. Дело в том, что раньше из документации можно было подумать, что обработчики AJAX-событий нужно описывать только в классе контроллера (если в бэк-энде), или компонента (если во фронте). И поэтому не очень было понятно, как быть, когда ты хочешь получить красивый ajax-пейджер для блога. То ли лезть в код чужого плагина, что влечет проблемы с обновлениями. То ли писать свой собственный компонент, из которого грузить компонент Posts программно. Что ведет к сомнениям в том, надо ли вообще такой негибкой CMS пользоваться.

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

У меня резинового утенка нет, но зато есть резиновый зомби. Он, как и утенок, ни фига не понимает, но если я буду плохо работать — он съест мои мозги.

Что мне всегда отдельно нравилось в Ларавеле — так это как там организована генерация тестовых материалов. Для этого используется мега-библиотека Faker, которая умеет практически всё, что может понадобиться при разработке. Годится как для автоматизированных тестов, так и для заполнения БД тестовыми данными.

В самом Ларавеле можно описать для моделей классы-factory и генерировать данные по ним, это описано в документации. В OctoberCMS про фабрики документация ничего не говорит, но можно обойтись и без них.

TL;DR: Далее несколько примеров генерации тестовых данных с помощью библиотеки Faker в OctoberCMS

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

Если исходить из того, что лого выводится в блоке Site branding, то вопрос решается вот таким небольшим кодом, размещенным в файле темы mytheme.theme:

/**
 *
 * hook_preprocess_block()
 *
 * @param array $variables
 */
function mytheme_preprocess_block(&$variables) {
  if ($variables['plugin_id'] == 'system_branding_block') {
    // определяем язык
    if (\Drupal::languageManager()->getCurrentLanguage()->getId() == 'ru') {
      $logo_name .= 'logo.svg';
    } else {
      $logo_name .= 'logo-en.svg';
    }
    $variables['site_logo'] = '/themes/mytheme/' . $logo_name;
  }
}

Файлы с логотипами, соответственно, хранятся в /themes/mytheme/logo.svg и /themes/mytheme/logo-en.svg. А если на странице несколько блоков с разными лого (например, в хедере и футере), различать их можно, проверяя содержимое $variables['elements']['#id'].

Вообще говоря, локализация интерфейса в OctoberCMS такая же как в Laravel. Есть файлы типа lang.php, разложенные по директориям, соответствующим языку, в них есть строки, их можно переводить. Неудобство лично для меня лишь в одном — когда нужно куда-то вставить локализованный текст, не видно самого текста, только идентификатор строки. В остальном, на мой взгляд, система эта несколько удобнее перевода интерфейса в Друпале.

Даже если поддерживать сайт или интерфейс на нескольких языках не нужно, с переводами можно столкнуться, например, при плюрализации, то есть склонении в зависимости от значения числа. Потому что в 2018 году уже как-то стыдно делать сайт, на котором написано «1 предложений», «22 предложений» и т.д. Надо склонять.

В Ларавеле это делается тривиально, для английского языка в lang.php пишем например:

return [
    'count' => [
        'offers' => 'offer|offers',
    ],
];

Тогда при вызове trans_choice('lang.count.offers', 10); выведется слово offers, а при trans_choice('lang.count.offers', 1); — offer.

И для перевода на русский достаточно добавить в соответствующий lang.php перевод:

return [
    'count' => [
        'offers' => 'предложение|предложения|предложений',
    ],
];

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

Но в OctoberCMS есть нюанс. Дело в том, что Ларавел поддерживает единую директорию lang для локализации всего проекта, поэтому туда можно складывать любые строки и обращаться тоже можно к любым строкам. А в Октябре у каждого плагина своя директория переводов, у ядра — своя директория переводов, а у используемой темы её и вовсе нет.

Из-за этого, в первый раз столкнувшись с задачей, можно немного смутиться — а как же сделать плюрализацию для строки, которую я просто в теме вывожу. Документация пока об этом ничего не говорит. А строчка:

Note: For translating front-end content, there are plugins that can be used for this purpose.

и вовсе может навести на мысль, что для перевода строк в теме (каковая и есть фронт-энд) нужно какие-то плагины ставить (нужно, но только для контента, то есть моделей из БД).

На самом деле для обращения к строкам локализации из темы, то есть из шаблонов Twig, есть фильтры. Для обычного перевода — фильтр trans, а для плюрализации — transchoice. Его и нужно применить, чтобы получить склоняемое количество предложений:

{{ "graker.touristic::lang.count.offers"|transchoice(quantity) }}

graker.touristic здесь — это обращение к плагину Touristic за авторством Graker: к сожалению, поскольку у темы нет своего файла локализаций, необходимые строки придется разместить в каком-нибудь плагине.

В Ларавеле вложенные (каскадные) отношения моделей — обычное дело. У автора есть записи, у записей есть комментарии, и так далее. Не менее обычное дело — необходимость удалять дочерние модели при удалении родителя. Самое первое, что приходит на ум — каскадное удаление моделей, которое включается при определении foreign-ключей и будет выполняться автоматически базой данных. Но у такого способа есть достаточно весомый недостаток: события deleting и deleted для удаляемых моделей не произойдут и их обработчики, соответственно, не будут вызваны. Ну, потому что удаление в БД происходит.

Поэтому, если существование обработчиков событий предполагается, лучше навесить удаление дочерних моделей на событие deleting модели родительской. Вот есть допустим модель Company и у нее множество моделей Contract, определенное вот так:

public function contracts() {
    return $this->hasMany('App\Contract');
}

Реализуем обработчик события deleting:

protected static function boot() {
    parent::boot();

    static::deleting(function (Company $company) {
        // здесь мы можем удалять контракты
    });

}

Но тут есть еще одна маленькая хитрость. Если мы напишем $company->contracts()->delete(), то контракты удалятся, но их события deleting и deleted тоже не произойдут. Дело в том, что contracts() возвращает нам не что иное, как Query Builder, и когда мы вызовем delete() — это будет обычный delete-запрос к БД. На эту тему даже иссуй есть.

Вызвать $company->contracts->delete() мы тоже не можем, потому что $company->contracts — это просто коллекция, нет такого метода у коллекции. Чтобы события сработали (например, чтобы удалить дочерние модели контрактов), нужно загружать каждую модель и вызывать delete() на ней. Примерно так:

static::deleting(function (Company $company) {
   $company->contracts->each(function (Contract $contract) {
       $contract->delete();
   });
});

Также подойдет метод Contract::destroy(), в который нужно передать массив с айдишниками контрактов — он сделает то же самое, что и приведенный выше код.

Допустим у нас есть форма и мы хотим в её интерфейс добавить какой-нибудь ajax-запрос к серверу. И Form API с его #ajax нам не поможет, потому что запрос происходит в каком-нибудь событии из сторонней библиотеки. В общем, надо сделать сервис и обратиться к нему через $.ajax(), или $.getJSON().

При этом, конечно, хотелось бы защитить сервис от CSRF. Ну и вообще, чтобы посторонние люди или боты не долбились по адресу сервиса без разрешения. Если бы запрос происходил через Form API, Друпал сделал бы всё за нас. Но и сами мы тоже можем, и на странице с формой для этого уже всё, что нужно — есть.

В Drupal 7 каждая форма защищена парой скрытых значений в $form['form_id'] и $form['form_token'], соответственно, мы можем их подобрать и использовать при отправке на сервер. Для простоты, сделаем эти значения частью пути к сервису.

var form = $('#my-custom-form');
var form_id = form.find('input[name="form_id"]').val();
var form_token = form.find('input[name="form_token"]').val();
var url = '/my-custom-service/' + form_id + '/' + form_token;
$.getJSON(url, function (data) {
    alert('Все готово!');
});

В hook_menu() пункт, отвечающий за генерацию ответа, оформим так:

$items['my-custom-service/%/%'] = array(
    'page callback' => '_my_custom_service',
    'access callback' => '_my_custom_service_access',
    'access arguments' => array(1, 2),
    'type' => MENU_CALLBACK,
);

То есть мы передаем в access callback эти два значения как аргументы. Тогда в функции, управляющей доступом, мы можем легко проверить валидность токена:

function _my_custom_service_access($form_id, $form_token) {
  return drupal_valid_token($form_token, $form_id);
}

И всё.