Подієва модель Laravel евенти в Eloquent та всієї системи в цілому, Laravel по-українськи

Відразу хочу попередити, що весь матеріал є у документаціях під тим чи іншим соусом. Я ж постарався скомпонувати всю інформацію щодо подій в одному місці.

Взагалі, що така подія у програмуванні? І ось що каже вікіпедія:

Подія це повідомлення, яке виникає в різних ділянках виконуваного коду при виконанні певних умов.

Іншими словами, програміст заздалегідь у своєму коді розставляє виклик подій, щоб у майбутньому мати можливість керувати поведінкою свого додатку залежно від ситуації без впровадження в ядро.

У базах даних існує таке поняття яктригер. Тобто. деяка процедура, що зберігається при настанні певних подій. Наприклад, додавання, видалення або оновлення записів у таблиці. Крім цього, для однієї і тієї ж події може бути створено 2 тригери - до настання події та після.

У Eloquent ORM так само. Creating – викликається до настання події створення запису. А created – після. Логічно припустити, що всього в ORM 10 подій:

Дія Подія до Подія після

створення	Creating	Created
Оновлення	Updating	Updated
Збереження	Saving	Saved
Вилучення	Deleting	Deleted
Відновлення	Restoring	Restored

Але не тут було. Їх 11. Існує ще подія boot, що викликається на момент отримання об'єкта. Я не назвав би це подією — чистої води ОВП. Але якщо про це згадано в документації — то варто торкнутися.

Ідея з boot полягає в тому, що ми розширюємо базовий методEloquent::boot доповнюючи його своєю логікою. Ось приклад розширення абстрактної моделі Test

Тепер давайте розглянемо як можна використовувати події за прямим їх призначенням:

Ідемо далі. І подивимося на ООП стиль подійності для створення/видалення/редагування записів. Тобто. За аналогією з методом boot прямо в самій моделі перевизначимо методи create, update або delete:

З погляду архітектури проекту, такий підхід зрозуміліший на дрібному і середньому проекті, т.к. все що стосується моделі - знаходиться всередині неї самої. А ось попередній спосіб і всі наступні рекомендується виносити, наприклад, файл/app/events.php за аналогією з /app/filters.php, який підключається при старті laravel. Тобто. із файлу/app/start/global.php.

Отже, наступний спосіб зареєструвати тригер за допомогою моделі спостереження. А ось реєструвати цей спостерігач можна як динамічно в залежності від умов, так і статично за допомогою методу boot:

При цьому, ніхто не забороняє поєднувати методи створення тригерів. Тобто. фактично, ми вже знаємо 3 різні способи завдання події для before create, after create. Точно так само і для update, delete.

Та й залишився останній, четвертий спосіб спостереження за подіями моделі. Останній і найпотужніший на мій погляд - Event:: listen:

Чому сильний? Тому що цей спосіб дозволяє слухати не лише конкретну подію, конкретну модель. Ми можемо почути відразу всі події eloquent. Можемо слухати усі події конкретної моделі. І допоможе нам у цьому козирна зірочка. Замінюємо їй потрібну частину імені події та воля.

Друга, найважливіша особливість фасаду Event у цьому, що дозволяє створювати довільні події. Допустимо, реєстрація нового користувача. Авторизація уадмінці і т.д. і т.п. Робиться це дуже просто за допомогою методу fire:

Ну, а слухати через Event::listen ми вже вміємо.

Крім реєстрації довільних подій, Event фасад вміє ще й поміщати тригер у чергу на випадок, якщо необхідно виконати якусь тривалу та ресурсомістку операцію.

Ну і нарешті Event підтримує передплатників. Так звані класи, які дозволяють навішувати одразу кілька тригерів на одну подію.

Із подіями на цьому все. Але перехоплення помилок свого роду також події. Тому хочу хоч коротко і про це розповісти.

Насправді тут все просто:

Але не на одному перехоплювачі проекти будуються. Адже у проектах може бути багато винятків. Починаючи з некоректного SQL-запиту та закінчуючи відсутністю прав доступу. Відповідно, логічно віддавати для різних винятків різні помилки. І тут допоможе приходить контроль типів.

Взагалі, реєстрація помилок відбувається у файлі app/start/global.php, якщо таких багато, то бажано винести в окремий файл як і події – допустимо в app/errors.php.

Крім методу error, є ще down – синонім для події illuminate.app.down. Назва, що говорить, - при завершенні роботи. Якщо зробити пошук за методом listen у папці vendor/laravel/framework, то можна знайти згадки про такі події, як:

artisan.start
illuminate.queue.failed
illuminate.log
illuminate.app.down
illuminate.query
router.matched
router.
router.filter:
auth.attempt

Ну і якщо вже торкнулися консольної команди artisan, то гріх не торкнутися події composer-а. Адже Laravel ставиться, оновлюється та встановлює компоненти саме через нього. Тому composer можна вважати по правучастиною laravel.

Для тих, хто не звертав увагу, комп'ютер підтримує цілих аж 18 подій до початку або після встановлення, оновлення або видалення пакета або самого проекту. Ці події вказуються в розділі scripts файлу composer.json. І після встановлення laravel там автоматично реєструються 3 події розібрати, які я вам усім пропоную вже самостійно.

Коментарі (2)

А ось попередній спосіб і всі наступні рекомендується виносити

взагалі винесло мозок. Хоча б нумерацію якусь запровадив (html: ordered list) чи розділив статтю підзаголовками. Хоч щось. Хрін зрозумієш, де поточний спосіб, який вважати попереднім і т.п.

UPD Перечитав ще раз, після копання у мануалі. Стало зрозумілішим, але все одно туго доходить.

Аффтар ацкей сотона пеші іщщо )))

Статистика: Символів - 6 287/5 329 без пробілів (5 234/4 446 без коду):, слів - 789