Спасибо, надо будет попробовать ларавел, посмотреть, что это.
А пока впечатления о другом мегапопулярном на территории бывшего СССР фреймворке.
Задача номер раз: есть два вида базового шаблона. Они почти одинаковы, только в одном из них вокруг контента обёрток поболее, чем в другом. Как мы такое делаем? Один шаблон наследуем от другого, в нём переопределяем блок, и всего-то делов. Как это делается в мегафреймворке: базовый шаблон один, никакого наследования нет. Более того, он порван пополам и живёт в отдельных двух файлах header.php и footer.php. Если нужна у разных шаблонов общая часть, то она складывается в третьем шаблоне и подключается функцией include().
Задача номер полтора: на одной из страниц в шапку нужно вывести кусок контента. Казалось бы… Нет, этот изврат у меня нет сил моральных описывать. Поверьте, всё очень плохо. Решаемо, но очень плохо.
Задача номер два: хитрая адресация в каталоге. Фактически один шаблон урлов на разделы каталога и отдельные товары. /catalog/section/ и /catalog/item/. Странность решения оставим на совести сеошников заказчика, которые на таком стояли принципиально. Как бы это у нас? один шаблон урлов сначала на вьюху раздела, затем на вьюху товара, только во вьюхе раздела get_object переписать, чтобы 404 не возбуждал. Но там… вьюх в мегафреймворке нет вообще. Или контроллеров. Есть визуальные компоненты. Это некие аналоги наших включаемых тэгов. Или плагинов в cms. Так вот компоненты бывают комплексными, тогда они занимаются обработкой урлов, и в зависимости от того, как поймут урл, подключают тот или иной простой компонент. Чтобы понять урл, приходится делать пару запросов в БД, проверить, есть ли нужный раздел или товар. Кстати, о БД. Такой сущности как модель, тоже нет. С натяжкой можно за аналог признать их собственное изобретение, именуемое инфоблоками. Что это: все элементы всех моделей свалены в одну кучу, в одну таблицу в БД, Почти целиком. Стандартная часть набора полей. А все поля, которые не вписались в стандартный набор, свалены в другую таблицу. Метод модели? О чём вы? Есть классы для работы с этим чудом. Классы почти целиком состоят из статических методов. То есть, объекты не создаются почти никогда. Только иногда. Когда именно? Наверное тогда, когда метод писал кодер, считающий, что объекты всё-таки должны создаваться. Более убедительной логики мне найти не удалось.
Задача номер три: интегрировать заказы магазина с CRM от того же разработчика. По рекламным хвалилкам это должно делаться путём нажатия одной кнопки. Естественно, это так не работает. Это вообще никак не работает. И другой возможности, кроме нажатия кнопки в админке, не предусмотрено. Уже скоро неделя как такую, казалось бы, простую, задачу, выполнить не получается. Для сравнения, аналогичная задача на YII2 (увиденный мною впервые в жизни на том проекте) с неизвестной науке CRM заняла около двух часов. На django с той же или любой дрйгой вменяемой CRM это заняло бы час. Здесь же замучена техподдержка, и самое вразумительное, что они смогли сказать: «наши специалисты поставлены в известность и работают над этим».
Люди! Django — это хорошо! Я сейчас просто смотрю, что вообще бывает. На очереди проект на рельсах. Они хорошие, но Джанго лучше. Следующий — на относительно новомодном фреймворке, с которым у меня ещё не было опыта. Интересно, что будет.
