Три с половиной способа доработки логики Битрикс24. Теория

Мы описали схему внедрения портала в статье « Битрикс24 — не игрушка. Внедрение корпоративного портала и CRM ». Сегодня — расширяем функциональность.

Скорее всего, после Большого внедрения потребуются программные доработки системы.

Как расширять функциональность Битрикс24 — нетривиальный вопрос.

Есть механизм создания бизнес-процессов, который может решить часть задач.

Но для многих ситуация “лезть в код” — неизбежно.

В первой части статьи мы углубимся в вопросы модификации системы. Будет больше технических подробностей.

Затем мы возьмем простую задачу и решим ее несколькими способами, сравним результаты и сделаем выводы.

Цель статьи — разобраться в том, как нужно правильно выполнять доработки системы Битрикс24..

Статья будет интересна специалистам по внедрению Битрикс24 с хорошим пониманием технологий.

Что такое Битрикс24 и как он работает

Мы имеем дело со стопкой технологий: Bitrix Framework, на котором основан 1С-Битрикс Управление сайтом, на котором, в свою очередь, построен Битрикс24.

Битрикс24 — сайт, разработанным на платформе 1С-Битрикс.

Каждый отдельный портал — копия сайта со своей базой данных.


Технически портал состоит ряда модулей (например, CRM, социальная сеть, телефония, задачи и другие), компонентов, и одного шаблона дизайна.

Каковы преимущества такого решения с точки зрения возможностей расширения функциональности?

Ответ печальный — их почти нет.

Мы много думали, спорили и совещались. Пришли к выводу, что хорошего способа развития логики Битрикс24 не существует.

Мы нашли несколько “приемлемых” и сегодня рассказываем о них.

Технологии доработки сайтов на 1С-Битрикс

В 1С-Битрикс предусмотрены различные точки расширения функциональности:

  • разработка собственного модуля,

  • обработчики событий,

  • разработка собственного компонента,

  • модификация логики компонента,

  • разработка собственного шаблона.

Проблема обновления корпоративного портала

Они эффективны при разработке или развитии сайта на 1С-Битрикс: Управление сайтом.

Можно ли так менять логику корпоративного портала? Почему мы не можем внести изменения в код модулей, компонентов, шаблонов?

При таком подходе возникнут проблемы с обновлениями:

  1. мы не можем выполнить обновление, поскольку оно удалит наши доработки;

  2. получаемые обновления не затронут разработанные нами модули, компоненты, шаблоны.

Каковы последствия каждой ситуации? В первом случае нам придется полностью или частично отказаться от полезных обновлений, за которые мы платим. В результате:

  • придется уживаться с существующими ошибками в системе,

  • придется отказаться от возможностей новых версий системы.

Во втором случае мы будем получать обновления, но:

  • они применяются к оригинальным составляющим системы, а используются их модифицированные копии,

  • если обновления не применяются к модифицированным копиям, то придется уживаться с существующими ошибками в них,

  • мы получим возможности новых версий системы, но модифицированные нами копии составляющих системы будут работать по-старому — новые возможности не будут доступны.

Теоретически, можно было бы выполнять слияние изменений, получаемых с обновлениями и внесенных нами. Однако в данном решении есть подводные камни, например:

  • чем больше изменений (с любой стороны) — тем сложнее слияние, каждое пропущенное обновление — потенциальная проблема;

  • если измененная часть системы будет полностью переработана, то слияние будет невозможным.

В любом случае мы обязаны сохранить возможность обновления.

Мы выделили три основных способа изменить логику Битрикс24.

Способ 1. Модификация логики через шаблон

В 1С-Битрикс есть механизм добавления логики в стандартные компоненты через файл result_modifier.php.

Данный способ связан с одной особенностью выбора системой шаблона для визуализации данных (это описано в официальной документации ): если в настройках компонента выбран встроенный шаблон и в шаблоне сайта «.default» определен шаблон компонента «.default», то он и будет применен.

Хотя это и звучит запутанно, на деле все очень просто.

Подробности на рисунке.



Рисунок 1. Переопределение встроенного шаблона.

Таким образом, если даже этот компонент входит в состав комплексного, он все равно будет отображаться с использованием созданного нами шаблона, если в комплексном компоненте не определен шаблон .default для него.

Теперь имеется возможность воспользоваться result_modifier.php, чтобы изменить или дополнить выход компонента.

Этот способ наиболее прост и очевиден.

Преимущества:

  • нет вмешательства в код компонента, что сохраняет возможность его обновления;

  • система автоматически задействует наш код;

  • простота.

Недостатки:

  • изменение шаблона в настройках компонента потребует реализовать те же возможности в новом шаблоне (конечно, маловероятно что у Битрикс24 будет пачка шаблонов, но все же);

  • обновления не затрагивают наш шаблон;

  • может потребоваться внести изменения в выходы разных компонентов;

  • размещение бизнес-логики в компоненте не корректно.

Способ 2. Модификации дерева DOM после загрузки страницы

В некотором смысле «крайний» вариант. 

Идея способа состоит в том, чтобы на стороне клиента с помощью некоторого JavaScript, после загрузки страницы, запустить необходимую логику, например, с помощью AJAX, а затем внести изменения в DOM-дерево, чтобы отобразить результат. В качестве альтернативного способа модификации страницы также может выступить обработчик события OnEndBufferContent, в котором мы можем получить доступ к HTML-коду, который будет отправлен клиенту. 

Однако серьезные доработки таким образом осуществить будет затруднительно, поскольку, фактически, нам доступна строка, содержащая код — в отличие от дерева, ее анализировать довольно сложно.

Далеко не все задачи могут быть решены таким способом.

Преимущества:

  • нет вмешательства в код Битрикс24, что сохраняет возможность обновления всех составляющих системы;

  • меньшая зависимость от механизмов работы 1С-Битрикс: больше возможностей для программиста.

  • подобный способ зарекомендовал себя во многих других проектах, еще до появления технологии «композитный сайт», пример — вывод количества лайков.

Недостатки:

  • неоправданно высокая сложность, связанная с анализом DOM-дерева;

  • сильная зависимость от используемого шаблона, поскольку им задается DOM-дерево;

  • потенциально, проблемы с кешированием: невозможно (или крайне затруднительно) встроить результат в кеш страницы или компонента, избавиться от запуска JavaScript, когда информация берется из кеша;

  • следствие из предыдущего пункта: данный способ может не подойти для слишком крупных доработок;

  • наибольшее из трех способов увеличение нагрузки на сервер и длительности загрузки страницы на клиенте.

Способ 3. Версионирование изменений

Раньше мы не вносили изменений в код модулей, компонентов или шаблонов Битрикс24.

А что если начать? А настолько ли это плохо?

Модификация кода Битрикс24 точно позволит достичь результата.

Более того, часто прямое редактирование кода даст отличный результат с точки зрения простоты решения.

Но — начнутся проблемы вместе с ближайшим обновлением. А обновления нам нужны.

Как устранить противоречие? На помощь придет система контроля версий.

3.png

Она «помнит» состояния кода в каждый момент времени, а также позволяет вычислять различия между ними. Этих простых возможностей достаточно для того, чтобы иметь возможность вносить изменения и не терять их при обновлениях.

Приведем пример того, как это работает.



Рисунок 2. Фрагменты графа изменений репозитория.

Сначала мы используем оригинальный код. Затем вносим в него изменения.

Это порождает новую ветку развития.

Затем разработчики Битрикс24 вносят в код изменения, развивают продукт, и выходит обновление Битрикс24.

Мы выполняем merge — слияние изменений. В результате появляется новая версия Битрикс24.

Данную процедуру будет необходимо проводить при каждом обновлении.

Это не просто, но гарантирует высокое качество и предсказуемость системы.

Современные системы контроля версий умеют почти все объединять без участия человека, кроме случаев конфликта слияния. Эта «магическая» процедура выглядит так



Рисунок 3. Очень упрощенный пример слияния (без вычисления трехсторонней разницы).

Конфликт произойдет в том случае, если в одном и том же участке кода будут сделаны изменения как нами, так и разработчиками Битрикс24 — в такой ситуации принять решение должен программист.

Единственный способ обновления 1С-Битрикс — его собственная подсистема SiteUpdate.

Чтобы схема работала верно, при каждом обновлении будет необходимо сначала переключаться на оригинальную версию Битрикс24, с которой последний раз производилось слияние, запускать SiteUpdate, и только потом выполнять слияние и запускать модифицированную версию.

Преимущества:

  • возможность изменять оригинальный код Битрикс24, в том числе API,

  • возможность получать обновления всех составляющих частей системы.

Недостатки:

  • разрешение конфликтов слияния может быть трудоемким процессом,

  • пропущенные обновления увеличивают вероятность возникновения конфликтов,

  • усложняется процесс обновления, он должен осуществляться при участии программиста.

Половинка способа

Мы назвали статью “три с половиной способа”.

“Половинкой” метода доработки логики мы считаем конструктор бизнес-процессов.

Это очень перспективно, но пока процессы мало где применимы и мало что умеют.

Выводы

Спасибо что дочитали. Мы знаем что было непросто.

Будем рады осмысленным комментариям.

Мы разобрали теоретически возможные способы программирования в Битрикс24.
Но — теория суха. В следующей статье — переходим к практике.

Читайте Пример решения задачи: «вывод списка не ознакомленных с сообщением» тремя способами .

Комментарии (0)