Блог программиста UMI CMS

UMI-Summit лета 2013 года: опасности UMI CMS 3.0

Рубрика: События, Сообщество разработчиков на UMI CMS

Сегодня (12 июля 2013 года) побывал на UMI-саммите.
Атмосфера, нужно признать, была весьма дружелюбная. Интересные доклады, много разных мнений и новых знакомств.
Немного жаль, что я не остался на второй и третий день, но уж обстоятельства так сложились — ничего не попишешь.

Самое интересное, что лично для себя я вынес из ЮМИ саммита — это конечно же презентация (ну или попытка презентации) UMI CMS версии 3.0.

Когда мы делали один из проектов для серьезного заказчика и тоже очень-очень не укладывались в сроки — наша презентация выглядела примерно так же: вот тут есть бирюлька и тут фишечка, а вот этот огромный функционал я вам не покажу так как это тестовая версия. Лично на мой взгляд все очень сыро и грустно.
Да, конечно, есть несколько позитивных моментов, которые действительно были показаны. Например, новый интерфейс. Но нужно четко понимать, что одно дело — интерфейс, а другое — то, что за ним стоит. И если последнего попросту нет, то и интерфейс незачем. (Я как всегда излишне придирчив 🙂 )

Если же говорить о концепте, то меня очень насторожили несколько идей, которые были положены в основу данной системы. Но наверное стоит излагать в порядке их полезности.
Очень положительные моменты:
— гибкая масштабируемость — пока неясно как реализовано, но звучит очень вкусно. Можно много серверов или БД или и того и другого. Полезно, хотя и редко применимо.
— многократно возросшее быстродействие (о боги, ну наконец-то)
— UMI.Store — наш ответ Битриксу. Пока доподлинно неизвестно как, но что вещь нужная — однозначно.

Фишки, вызывающие сомнения и непонятки:
— системные страницы в структуре (это типа /emarket/cart). Вроде как это и полезная штука — делает систему более прозрачной, но она так же создает определенную нагрузку на пользователя. Надо не забыть указать страницу, реализовать её вывод и передать эти данные во все модули системы. Как это возможно сделать — пока неясно.
— взаимодействие между модулями через API. Тут как бы вроде больше позитива чем недопониманий. Но пока не видно API — непонятно к чему готовиться и как взаимодействовать. Да и нужно понимать, что я в любом случае могу провзаимодействовать между модулями через что угодно. И попробуй меня останови. Поэтому, очень надеюсь, что целью этого нововведения была помощь во взаимодействии, а не новые препятствия на пути.

Теперь самое сложное и весьма-весьма сомнительное:
— Цитата «Framework и CMS в одном флаконе». Боюсь спросить: теперь настроить систему из коробки обычному пользователю будет вообще нереально? Надеюсь, что это не так. Но время покажет. Могу по своему опыту сказать: еще ни разу не пользовался UMI CMS Framework, хотя он вроде бы даже существует.
— новая «нормализованная» структура БД. Нда…. Ну что тут скажешь? «Раньше мы думали что лучше много мелких запросов, а теперь — что лучше один большой». Ощущение метания из крайности в крайность. И та и другая структура таблиц и данных (если я правильно понимаю о чем в этой «фишке» идет речь) имеет как свои плюсы, так и свои минусы. И я даже понимаю, почему разработчики решили уйти от той структуры в новый вариант. Но все это пока что звучит очень туманно. Будем надеяться, что реализация не подкачает и получится все хорошо и слаженно.
— новые механизмы шаблонизации: поддержка не только TPL и XSLT, но и PHP, Twig, Smarty, и некоторых других (на самом деле, почти неограниченное количество, но конечно нужно писать самостоятельно). Ну по этому поводу у меня есть «об чем вам сказать».
Кто вообще додумался делать новые шаблонизаторы в UMI? Это очень мне напомнило административное решение без детальной проработки и понимания сути происходящего (да не в обиду руководству это будет сказано).
Понятно, что целью подключения произвольного шаблонизатора для произвольного модуля является увеличение популярности UMI среди разработчиков. Правильнее будет назвать таких людей слабоподготовленными нытиками, которые говорят: вот XSLT очень сложный язык, порог входа в вашу систему очень высокий, бла-бла-бла.
Да, специалист, знающий XSLT на рынке нынче дороже, чем студент, который прочел методичку по PHP и знает пару команд. Но разве же это не показатель профессионализма тех людей, которые разрабатывают для клиента сайт на системе управления? Разве же это не показатель того, что люди будут делать свою работу качественнее и лучше? Что они не поленились и выяснили что это за язык, узнали его особенности и возможности. Да вообще-то там и узнавать-то особо нечего. Так, пара-тройка команд.
Но что же даст это в дальнейшем?

Ну, для начала, мы получаем полный ….. Единственное, что приходит на ум из цензурной лексики — хаос. Реально получается полный хаос. Открываем мы сайт клиента, который сделан на UMI CMS и который мы пообещали поддерживать и о…балдеваем (опять рвется наружу родная речь) от тех конструкций, что использовались авторами сайта. Мало того, эти конструкции уже и сейчас вызывают огромный и неподдельный интерес, а так же бурю эмоций. И это несмотря на то, что сейчас (в версии 2.8-2.9) есть только лишь 2 шаблонизатора (зачем оставлен TPL — ума не приложу). А на чем будет реализован стандартный demodizzy? На Twig-е? Да это блин даже не язык. И в нем не существует и 50% функционала XSLT. Как работу, которую раньше можно было легко реализовать на XSLT теперь сделать под Twig?

А как с этим (о господи, оказывается нужно было подумать и о внутренних процессах в компании) справится Служба Заботы? «Простите, мой Smarty-шаблон не хочет функционировать. Не подскажите, как запустить его на простом PHP?»

В общем, из уникальной системы с революционными взглядами на внутреннюю структуру и принцип работы, UMI CMS выростает во второсортную «универсальную» систему управления сайтами, коих на рынке уже достаточно немало.

Что-то я слишком яро пытаюсь отговорить не принадлежащую мне компанию от катастрофических шагов. Вероятно мне не стоит этого делать и время все расставит на свои места. (Пообсуждав в колуарах мы подумали о том, что в лучшем случае останется XSLT, а остальные шаблонизаторы прекрасно умрут своей смертью. В худшем — умрет UMI CMS как коммерческий программный продукт. Посмотрим.)

Резюмируя свою бурную речь: пьянка удалась, а тройка так и не маячит на горизонте.