Мало кто задумывается, что программирование любого веб-проекта на PHP - по сути такое же параллельное программирование, как если бы вы делали это в более низкоуровневых языках, таких как "C" или "Erlang". Когда на ваш сайт идёт поток траффика, на нём в один и тот же момент времени параллельно и одновременно отрабатывают множество экземпляров ваших PHP-скриптов. А значит между ними могут возникнуть классические эффекты "ожидания и опережения", когда нужно предусматривать строгую последовательность выполнения данных.
В то же время, любой достаточно длинный алгоритм требует больше ресурсов, а так же более сложен в отладке и в тестировании. Когда вы в сложном проекте программируете длинную цепочку (или большой набор) взаимосвязанных действий, вы закладываете самому себе фундамент для головной боли при отладке на конечных этапах проекта. Чем больше вы связываете функции между собой, тем более вы нарушаете принцип инкапсуляции - одной из четырёх основ правильного программирования. И сложная логика грозит вырасти в клубок связанных действий, который придётся распутывать каждый раз заново.
Поэтому при разработке сложного проекта крайне важно с самого начала использовать так называемую событийную (events) модель, когда ряд действий не связывается непосредственно между собой и не выстраивается в длинные цепочки. Каждая функция живёт, развивается и тестируется независимо. А когда вам нужно сделать два действия последовательно, то первое из них должно подать сигнал, а второе - услышать его и сделать свою часть работы. И так далее.
Первый шаг, который вы должны сделать в UMI.CMS на пути изучения основ асинхронного (параллельного) проектирования, это узнать как у нас устроена событийная модель. К сожалению, очень многие разработчики знают о ней крайне мало. Поэтому мы расширили соответствующий раздел документации, чтобы раскрыть этот вопрос более подробно:
Событийная модель UMI.CMS
Стандартные точки вызова событий
Вы будете удивлены тем, как много событий в Юми можно "мониторить" и добавлять свои действия, совершенно не влезая в исходный код и не нарушая его целостности. Удачной вам работы!
Комментирование доступно только авторизованным пользователям.
Пожалуйста, зарегистрируйтесь или войдите на сайт.
Григорий, может быть немного оффтоп, но все же - когда будет решение относительно почтовых шаблонов?
Две основные проблемы: интернет-магазин (уведомления во время заказа) и уведомления при регистрации.
Почти все заказчики требуют, чтобы им приходили полноценные уведомления (с деталями заказа), а этого нет.
А при регистрации, даже название сайта не подхватывается из regedit, по-умолчанию вписано в почтовом шаблоне .tpl... Несерьезно :)
Такое ощущение, что редактирование почтовых шаблонов забросили еще с времен tpl...