Разбор ООП с Delphinum

# Koenig (04.12.2016 / 19:01)
Delphinum, можно на пальцах обрисовать взаимодействие eventmanager из zf так как я что то не догнал, когда он все успевает регистрировать

взаимодействие с чем?

# AlkatraZ (04.12.2016 / 21:46)
Вопрос: ЗАЧЕМ?
Убедительного ответа я даже из первоисточников не получил.

Целей несколько:
1. Если необходимо сформировать SQL запрос машинно (читай автоматически), но не одним объектом, а несколькими, путем навешивания и навешивания новых, к примеру, условий в запрос в зависимости от каких то параметров
2. Для унификации, так как не смотря на то, что SQL является стандартном, все его реализации отличают (смотри тот же LIMIT), а Builder позволяет свести все к одному интерфейсу
3. Для новичков, не знакомых с SQL и базами данных, но знакомых с объектами. Поверь, в крупных конторах такого добра навалом, и их проще обучить работе с Builder, чем с SQL и реляционной алгеброй

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

# AlkatraZ (04.12.2016 / 22:07)
Не. генерится то в зависимости от контента
К примеру в библе, если статья с картинкой?
Там верстальщик не причем.

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

Delphinum, да хотя бы с mvc
просто какая то скрытая работа у событий. не пойму я эту магию. где начинается и где заканчивается

Koenig, у mvc событийная модель запутанная, согласен. Сам далеко не сразу в нее въехал.

Если на пальцах то нужно два объяснения:
1. Событийная модель в общем
Смысл здесь в том, чтобы использовать события не просто как точки для реакции на работу алгоритма (обычно события используются именно так), а как точки "включения" в этот алгоритм. Вот пример:

class Router{
  ...
  public function route($uri){
    // Событие для разделения URI на части
    $uriComponents = $this->eventManager->trigger('prepare', ['uri' => $uri]);
    // Событие для роутинга по частям URI
    $controller = $this->eventManager->trigger('route', ['uri' => $uri, 'components' => $uriComponents]);

    return $controller;
  }
}

Класс с такой моделью это как паттерн "Шаблонный метод", но работающий через события (то есть более гибкий и динамический). Ты можешь навешать на события пачку обработчиков, который будут получать и обрабатывать URI и тот из них, кто первым вернет результат, и будет использоваться роутером для работы.

Модель сложная, не очевидная, но очень гибкая, потому применяют ее редко и по минимуму.

2. ZendMVC
Логика совершенно такая же, объект MVC просто генерит пачку событий, а всякие службы эти события ловят и обрабатывают, тем самым запуская приложение (вызывая роутер, затем контроллер, затем шаблонизатор). Выгода тут в том, что модули Zend (которые ты пишешь) могут так же слушать эти события (регистрируясь в метода onBootstrap класса Module) и как то на них реагировать, подменяя работу роутера, на пример.

Навешивает все эти системные обработчики на ZendMVC объект логика, запрятанная под App::init() который у тебя вызывается обычно в index.php

# Delphinum (05.12.2016 / 11:44)
1. Событийная модель в общем

Честно говоря, я считаю "событийную модель" насильно притянутую "за уши" и не подходящую для мира РНР.
Объясню на пальцах:

РНР - это скрипт, который отработал текущую сессию и отвалился. Тут теоретически (сильно упрощая понимание) никаких событий быть не может. Все задание мы получили в Request, в процесе выполнения никаких дополнительных заданий от клиента уже не поступит и мониторить какие-либо события нет смысла (точнее, прогеры сами выдумывают себе события и отрабатывают их гг).

MVC писался для языка SmallTalk, а на нем уже пишется уже прикладное ПО для компьютера. Это ПО находится в запущенном состоянии и разумеется имеют место быть всякие события, типа нажатия кнопки и т.д.

AlkatraZ, в мире php события аналогичны паттерну Observer, и так же используются. Это не то же самое, что события в JS на пример.

Лично я для себя выделил новый паттерн, который можно назвать "контроллер событий" или "экшены событий". Очень полезно для систем, которые сопровождают операции пользователя какими то связанными действиями, типа: отправить письмо по email, отправить SMS, оповестить "учителя" и т.д.

# Delphinum (05.12.2016 / 15:12)
AlkatraZ, в мире php события аналогичны паттерну Observer, и так же используются. Это не то же самое, что события в JS на пример.

Я не про это, а про событийное построение MVC.
Да, таковым являлся классический MVC в SmallTalk, но для РНР - это излишняя сложность.
То же самое можно зачастую решить намного проще.

AlkatraZ, нет, в зенде MVC построено не по классическим канонам SmallTalk, там другая реализация. Говоря коротко, зенд не пытается связать представление с моделью через события, как это предложено в классическом MVC, зенд предлагает шаблон для создания очень гибких классов, основанный на событии. Класс не выполняет какой то алгоритм, а просто последовательно бросает пачку событий и возвращает результаты их обработки. Это довольно необычная схема, потому многим она не понятна сходу.

# Delphinum (05.12.2016 / 15:19)
AlkatraZ, нет, в зенде MVC построено не по классическим канонам SmallTalk, там другая реализация. Говоря коротко, зенд не пытается связать представление с моделью через события, как это предложено в

Ну Зенд - там вообще отдельная страна, хотя мне лично их подход нравится больше всего, ибо классический.

а просто последовательно бросает пачку событий и возвращает результаты их обработки

Они с прошлого года выкатили дальнейшую реализацию этого механизма (собственно именно на нем и планирую делать mobiCMS). Там уже про классические "события" можно забыть. Вместо этого есть Middleware и пакет zend-stratigility, который является "крутилкой-исполнялкой" этих middleware.

Там уже с помощью конфигов ты выставляешь нужную цепочку мидлетов, определяешь приоритет их выполнения и получаешь профит.
С точки зрения "понимания", намного очевиднее и логичнее, чем с евент-менеджером.