Рано или поздно, любой разработчик Битрикс сталкивается с ситуацией, когда базового функционала ему перестает хватать. Именно тогда ему и приходится вникать в процесс разработки компонентов(или модулей). На первый взгляд задача кажется достаточно сложной, но изучив суть вопроса, она такой не является.
Смотря книги (обычные печатные), почитая статьи и форумы в интернете, я находил материал, который может дать только поверхностное представление о компонентах. Но, думаю, для понимания его принципа работы и грамотного написания стоит изучить архитектуру Битрикс Фреймворк.
Архитектура этой платформы строится по модели MVC(модель – представление - поведение):
На рисунке сплошными линиями отмечены прямые связи, пунктиром – косвенные.
Теперь давайте рассмотрим, что из себя представляет компонент Битрикс. Компонент – логически законченный код (логика), который получает информацию и выводит ее в определенной форме(шаблон, как правило html). Используемые в Битрикс компоненты можно разделить на простые(одностраничные) и комплексные(набор простых, многостраничные).
Папки:
Все компоненты Битрикс бывают системными и пользовательскими, они располагаются в /bitrix/components/.
Системные находятся в /bitrix/components/bitrix/, пользовательские – в самой папке в /bitrix/components/ или любых других подпапках. Размещение пользовательских компонентов в папке /bitrix/components/bitrix/ крайне не рекомендуется, т.к. они будут затерты после первого обновления системы. Также не рекомендуется менять системные компоненты, итоги таких изменений могут быть плачевными.
На этом заканчиваю «сухую» теорию компонентов. Статья сыроватая, вскоре может быть дополнена или даже переписана.
Рад любой конструктивной критике!
Смотря книги (обычные печатные), почитая статьи и форумы в интернете, я находил материал, который может дать только поверхностное представление о компонентах. Но, думаю, для понимания его принципа работы и грамотного написания стоит изучить архитектуру Битрикс Фреймворк.
Архитектура этой платформы строится по модели MVC(модель – представление - поведение):
- модель – это API,
- представление – это шаблон,
- поведение – это компонент.
На рисунке сплошными линиями отмечены прямые связи, пунктиром – косвенные.
Теперь давайте рассмотрим, что из себя представляет компонент Битрикс. Компонент – логически законченный код (логика), который получает информацию и выводит ее в определенной форме(шаблон, как правило html). Используемые в Битрикс компоненты можно разделить на простые(одностраничные) и комплексные(набор простых, многостраничные).
Структура компонента
Компоненты Битрикс расположены в отдельных папках, имеют чёткую структуру и обладают свойствами неделимости(их файлы нельзя использовать по отдельности).Папки:
- help не является обязательной, в ней располагаются файлы помощи,
- install содержит скрипты по установки(и удалению) компонента, ее наличие не обязательно в системе,
- lang содержит подпапки для языковых параметров компонента, ее наличие тоже не является обязательным,
- templates содержит шаблоны компонента, если у компонента нет шаблона, то папка может отсутствовать.
- сomponent.php содержит логику компонента, его наличие всегда обязательно,
- .description.php является необходимым, служит для задания названия, описание, нахождения в дереве логического размещения (визуального редактора),
- .parameters.php – необходим для задания параметров. Если у компонента нет вводимых параметров, файл может отсутствовать.
Расположение компонента
Системные находятся в /bitrix/components/bitrix/, пользовательские – в самой папке в /bitrix/components/ или любых других подпапках. Размещение пользовательских компонентов в папке /bitrix/components/bitrix/ крайне не рекомендуется, т.к. они будут затерты после первого обновления системы. Также не рекомендуется менять системные компоненты, итоги таких изменений могут быть плачевными.
На этом заканчиваю «сухую» теорию компонентов. Статья сыроватая, вскоре может быть дополнена или даже переписана.
Рад любой конструктивной критике!