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

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

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

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

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

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

Простой и понятный online-курс для обучения XSLT-программиста с любого базового уровня

Июл12

5 комментариев на «UMI-Summit лета 2013 года: опасности UMI CMS 3.0»

  1. Для чего уберать tpl и оставлять xml, если вам удобнее работать с громозким xml работаейте, система дожна иметь несколько шаблонизаторов. Дело выбора разработчика.

  2. Алексей пишет:
    13 Дек 2014 в 11:16

    На мой взляд XSLT это для извращенцев, когда есть PHP. Идеальные фреймворки имеют MVC модель, где представление отлично пишется на PHP. XSLT это сущий ад для мозга. Так, что идеально оставить PHP шаблонизатор и вычистить все что сделано на XSLT. точно так же про стоимость сециалиста XSLT на рынке туда.. Чем мутнее технология, тем почему то дороже спец.. а то что он не эффективен и делает ту же работу что и на PHP, только в 5 раз сложнее никто не знает..

    • Алексей, я конечно могу ошибаться, но на мой взгляд ваше сообщение больше выглядит как: «Не могу найти нормального разработчика на XSLT, все хотят много денег, а я хочу сам и подешевле. А сам я XSLT не знаю, да и не вижу в новых знаниях необходимости.»

      Каждая технология создана для своих нужд. В разных случаях удобнее применять разные вещи. Есть фреймворки, есть чистый PHP, если Python и еще очень большое количество разных языков и технологий, применяемых в вебе. Не будете же вы утверждать, что нужно отказаться от всего этого и оставить только одно 🙂 Как минимум, такой вариант будет лишать PHP конкуренции.

      Холивары о том, что одна технология круче другой — это пустая трата времени. Нужно смотреть на цели. Лично я рекомендую вам ознакомиться со всей мощью технологии XSLT на конкретных примерах и может тогда вы поймете зачем все это и как с этим проще работать. И тогда у вас будет обоснованное понимание где и что лучше применять.

      Хотите — можем даже попробовать какую-нибудь совместную разработку. Пишите — договоримся об условиях сотрудничества 🙂

  3. Алексей пишет:
    14 Дек 2014 в 14:07

    Александр, спасибо за ответ.

    Видимо сказывается мой предыдущий огромный опыт работы с разными PHP-фреймворками, где я в одной строчке делаю функионал такой же как листах 2-3 кода на XSLT в котором 90% текста просто создание шаблонов, условия, контактинации итд итд..

    Я просто хотел бы видеть PHP-шаблонизатор помимо XSLT в коробке тройки, как и Smarty, Twig итд) Уверен с этого момента сложность сайтов и функционал юми возрастет до небывалых высот, ибо появится реально самый мощный вариант шаблонизации. Да и структура юми надеюсь уйдет от XML представления результатов.. Как пример Bitrix-фантастические возможности, без ограничений шаблонизаторов.

    XSLT я знаю, да может не все тонкости, но делал сайты на нем. Реально у меня одно лишь оправдание есть XSLT — это XML структура у юми-смс.

    По поводу сотрудничества- покажите портфолио) есть ли там сложные проекты?

    • Портфолио вот: http://a25.ru/portfolio/

      Есть разные сайты: от простеньких сайтов-визиток до больших интернет-магазинов.

      Не ищу оправдание XSLT — вижу проблемы в битриксе, которые нельзя просто решить средствами PHP 🙂 Но видимо у каждой технологии есть такие подводные камни.

Ваш отзыв