Как приобрести уверенность в завтрашнем дне, работая с Bitrix - компонентами.

Мы, разработчики, добавляем к ним новый функционал, кастомизируем, стараемся их улучшить, но верно ли мы это делаем?

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

Разберем возможные развития событий:

1. Правим прямо там где написано.
   — А давайте исправим компонент Битрикса прямо в папке /components/bitrix?! Это дурная практика, которая ни к чему хорошему не приведет. Таким способом мы, конечно, быстро решим проблему, но при очередном плановом обновлении CMS-ки все изменения будут утеряны. Прощайте часы, а то и дни работы! Если есть доступ к серверу, то нам очень повезло, а вот если нет… то вспоминаем что писали.

   ClickON не советует!

   
   
   
   
   
2. Делаем запрос в result_modifier.php

   Практика неплохая, но со своими минусами.

   Компоненты вроде catalog.smart.filter кешируются, но их шаблоны кэшироваться не будут и делать запрос в result_modifier.php - это не самое лучшее решение, т.к. он будет исполняться на каждом хите. Кому это надо?

   Другое дело, если шаблон кэшируется. Например, как в компоненте news.list. В этом случае можно запросить, что-то не тяжелое, вреда от этого почти не будет, если сайт не сильно нагружен. Так будет сохранена совместимость с будущими версиями продукта.

   Частично надежный метод, который можно применять в проектах, но с оговоркой.

   ClickON призывает быть внимательным с этим способом.

   
   
   
3. Копируем компонент в своё пространство имён.

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

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

   ClickON призывает подумать, есть ли умения и навыки поддерживать такой проект.

   
   
   
4. Если компонент описан в стиле ООП, отнаследуй его.

   

   На сегодняшний день в разработке считается нормой использование ООП (Объектно ориентированное программирование). Мы все привыкли к этой парадигме и стараемся максимально полезно использовать его постулаты (3 слова, которые каждый из нас должен знать :)).

   Компания Битрикс уже давно стала внедрять ООП в компоненты. Это хорошая тенденция, одна из целей которой служит избежать лапши-кода в файле component.php. Мне нравится описывать компоненты в стиле ООП в Битриксе. НО всегда есть подводные камни, на которые мы можем неожиданно наткнуться.

   Если у компонента есть поддержка класса, то можно создать свой компонент просто отнаследовав его.

   Можно с легкостью добавлять новый функционал к уже имеющимся компонентам. Переопределить нужные методы, добавить свои и делать все что, нужно. НО! Делать так стоит только в том случае, если есть уверенность, что при обновлении родительский компонент не затронет функциональность дочернего.

   Делать это с компонентами Битрикса, я бы категорически не рекомендовал, если планируешь обновлять Битрикс. Иначе при обновлении могут ждать неприятные сюрпризы.

   Битрикс предупреждает - изменения родительского компонента может повлиять на его работу!

   При изменении базового класса компонента нужно учитывать поведение ВСЕХ его потомков (других компонентов).

   Но если решится на такой отчаянный шаг, то при каждом обновлении нужно следить за работоспособностью компонента. Если он не выполняет свою задачу так же как до обновления, то стоит подгонять его под новые рельсы родительского компонента. Задача, не самая приятная, т.к. времени на неё может уйти от 5 минут до плюс бесконечность.

   ClickON не советует! Но если нет выбора...

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