UMI EIP — бессмысленный и беспощадный

Рубрика: Решения, Тонкости UMI CMS

Этот текст был подготовлен для встречи сообщества разработчиков сайтов на базе UMI CMS для встречи 28 апреля 2015 года.

Используете ли вы EIP в своей работе при создании сайтов на UMI CMS? Лично я использую и считаю его неотъемлемой частью любого клиентского сайта. Однако, в очень большом количестве проектов, которые мне доставались «по-наследству», я не находил даже следов Edit-In-Place технологии. Сегодня я попробую выявить причины этого и вместе с вами преодолеть их.

Полезность

EIP в UMI CMS, на мой взгляд, реализовано на порядок лучше, чем в других CMS, с которыми мне довелось работать. EIP в ЮМИ не содержит ничего лишнего. Да, тут нельзя подвинуть компоненты, добавить их или убрать, но это и не нужно. Все это не должно отвлекать пользователя сайта от самого главного — наполнения сайта контентом.

EIP в UMI понятен и прост. Он не требуется никаких специальных знаний и даже рядовому пользователю очевидно как редактировать сайт.

Однако, при всех этих достоинствах, разработчики все еще не внедряют его на сайты. В чем же дело?

На мой взгляд, основная и единственная проблема — это относительная сложность внедрения. Я говорю именно относительная, так как имея перед глазами понятное типовое решение можно в достаточно обозримые сроки (в среднем, минут за 30 тривиальной работы) достигнуть нужного результата.

Вот они, проблемы

Итак, у вас есть прекрасно работающая юми и отлично сверстанный шаблон. Отдельно они работают как часы. Соединяем их простым копированием и… Ничего не работает. Вся динамика и все спецэффекты пропали враз. Бывает и хуже — только часть эффектов работает. Это еще труднее диагностировать.

Что же случилось с двумя нашими безупречными составляющими? В большинстве случаев оказывается, что ваш шаблон тоже использует jquery, как и подключаемые скрипты юми. И вроде неплохо иметь jquery подключенным по-умолчанию, но версия библиотеки очень старая. А ваши слайдеры и вся динамика с такой версией работать просто не готовы.

В идеальном мире я бы подумал, что самым правильным способом решения этой ситуации было бы упаковывание штатного jquery в noconflict. Но, к сожалению, мы не в идеальном мире. Нам придется что-то делать с этим так, как это есть сейчас.

Решение

Как поступаю я:

  1. В месте, где я осуществляю подключение скриптов, самым первым идет вызов моего jquery. Вообще не важно какой версии и откуда я её беру — могу даже из гугла тянуть.
  2. Затем обязательно следует вот такая конструкция:

    <script>
    var myJQ = jQuery.noConflict();
    </script>
    С её помощью я закидываю свой jquery в noconflict.

  3. Теперь мне нужно заставить мои скрипты работать с новым JQuery. Для этого я использую 2 строки в начале и в конце каждого подключаемого мной JS-скрипт.
    В начале:

    (function($,jQuery){
    В конце:

    })(myJQ,myJQ)

  4. И в самом конце, уже после всех своих скриптов, я подключаю стандартный механизм EIP:

    <xsl:value-of select="document('udata://system/includeQuickEditJs')/udata" disable-output-escaping="yes" />

Теперь для обращения к своим библиотекам я использую не $, а myJQ. И все работает как нужно.

Да, первоначальная работа немного запарная. Но она чисто механическая и вполне предсказуема по трудоемкости. Поэтому, на мой взгляд, данное решение достаточно хорошо подходит для большинства проектов на UMI CMS.

Дерзайте, внедряйте полезные и приятные вещи — и клиенты будут вам благодарны.

Апр30

Информация о статье

Метки:

Ваш отзыв