Удобные компоненты для Битрикса

В этой статье речь пойдёт о некотором моём предложении для сообщества. Это вдвойне сомнительное предложение из-за того, что мой личный трип на битриксе уже закончился. Две недели безвылазно на учёбе плюс где-то неделя в ритме «пытаюсь себя заставить» и… И вот статья. Держите. Надеюсь, кому-нибудь пригодится.

Как пишутся компоненты сегодня

Вы создаёте папку в пространстве имён внутри вашей папки local/components/. В битриксе под «пространством имён» понимается нечто, не слишком связанное с psr-4, но всё таки. Всё таки сам этот psr-4 — только плод договорённостей. Так почему бы и нет. Каждый может определить «пространства имён» как хочет — просто дальше ему и товарищам с этим жить.

Говоря конкретнее, пространство имён на битриксе — это… папка. Вот, например, в папке local/components/maryrabinovich/ были бы компоненты моего имени. Если вдуматься, в psr-4 пространства имён в целом достаточно точно соответствуют файловой структуре: классы из App\Components\MaryRabinovich\ ищутся в папке src\Components\MaryRabinovich\, т.е., в этом месте особенно ничего нового.

К этому можно привыкнуть.

Я создаю подпапку в папке моего имени. Я называю её именем компонента, который делаю. Что-нибудь вроде папки local/components/maryrabinovich/mygreatcomponent/. Дальше, внутри, я создаю а) файл компонента component.php, б) файлы настроек .parameters.php & .description.php, в) языковые папки, г) папку с шаблонами компонента. Может быть также д) класс компонента.

Это — стандартный набор. Внутри битрикс под это заточен: он изначально ищет такие файлы при рендеринге компнента.

Как используются компоненты сегодня

Спойлер: с трудом. Надо пойти в визуальный редактор, добавить тестовую страничку (желательно, чтобы что-нибудь ненароком вокруг не задеть), переключиться на редактирование этой страницы, найти компонент в длинном списке (в котором отдельные пункты сворачиваются и раскрываются… поиск сам по себе — довольно долгое дело), добавить на эту страничку. В правом верхнем углу сместить ползунок в «режим редактирования», навести мышку на компонент, нажать выпадашку «скопировать файлы». Файлы появятся в вашей папке шаблона (если вы дочитали до этого места, скорее всего, вы и так знаете продолжение).

Выход на визуальный редактор — это минута времени. Но не только.

Это полное отвлечение от работы. Если, конечно, мы под работой подразумеваем код. Код или bash — ту ситуацию, когда вы копируете через copy.

Далее. Визуальный редактор, сам по себе, это вещь, от которой отвлечься — уже не минута. Это уже легко минут десять, прийти в себя. После ещё десяти, пока вы там кнопки искали.

Для чего оно так

Что именно происходит, когда вы на визуальном редакторе ткнули «добавить сюда эту вот компоненту»? Вставляется код.

Какой? Вставляется простыня с вызовом компонента.

Куда? В то место вёрстки, куда вы сейчас его (компонент этот) вставили. Если хотите перенести его в другое место, вы вырезаете простыню, переносите и вставляете.

Как она формируется? Вроде, нигде внутри собственно компонента этого кода нету… И да, и нет. Этот код есть в зачатке в файле .parameters.php. Там же километровый массив с обозначениями: что за ключи нужны, каких типов, значения по умолчанию.

И вот из этой штуки битриксова админка делает простыню. Ради которой вы ходите на редактор, нервничая, страдая, ищете компонент в списке, дальше туда-сюда кликаете, чтобы скопировать.

Как в этом убедиться, не глядя в код обработчика из битриксовского визуального редактора? Очень просто. Добавьте ещё параметр в этот файл (.parameters.php). Ещё один ключ. Выйдите в визуальный редактор (и вот это всё проделайте), и убедитесь, что новый параметр выскочил перед носом в вызове компонента из вашей вёрстки.

Мелкое примечание для ларавеллистов: это что-то вроде местного vendor:publish.

Простейший, ну очевидный же способ это вот обойти

В новых (хотя бы в новых, но в старые-то что мешает добавить) папках под компоненты надо к типичному набору файлов добавить папку calls/ с файлом example_call.php .

Файл будет не для использования напрямую, а для копирования. Он будет содержать эту простыню в типовой своей форме. Можно будет обычным copy скопировать себе каталог, куда надо, дальше ненужное потереть. А вызов переназвать по имени того места, куда вы его вставляете и добавить в вёрстку через require. Я проверяла: эту конструкцию визуальный редактор видит и может потом корректировать, как и прямую вставку.

Если вам надо вставить один компонент в три страницы, причём по-разному, вы из example_call.php делаете call1.php, call2.php, call3.php. Или как-то читабельнее, вроде callFromMainPage.php, callFromFooter.php и др. Раз вы вставляете их require-ом, вы тут хозяин названиям на 100%.

Минусы такого решения

Код получается, как бы сказать, ненормированный. В том же смысле, как базы данных бывают нн. Вроде бы, вот .parameters.php, и вот этот calls/example_call.php . Что если вы про свой компонент внезапно вспомнили, в одном файле из этих двух что-нибудь поменяли, дальше вас отвлекли обедом-супом или, скажем, звонком. Ну и ваш второй файл остаётся без правок. И что тогда? Или, наоборот, вы выправили что-то в экзампле, и позабыли выправить это в параметрах.

Ну… бывает. Естественно, это возможно. Но битрикс и ненормированность — это как бы синонимы, разве нет?

Собственно, что происходит с вызовами компонента после того, как вы исправляете .parameters в его исходной папке? Как-то там корректируется ваш вызов. При первой же правке. Ну вот и тут, похоже, он скорректируется. По структуре — при этом место, сам этот путь к вызову calls/call1.php корректироваться не будет. И ваша вёрстка останется чистой, там будет только require.

Небольшая справка по истории этой идеи

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

• начальство мне отвечает, что так нельзя. Сам компонент не должен ничего знать о своих где-то вызовах. «Можешь добавить этот свой код как readme».

• я думаю: ну какое ридми, когда это — код php, собственно, что-то навроде .env.exemple из ларавель… ах да. Вот, делаем файл example_call.php и на каждое применение как-то его модифицируем своим образом. Поскольку может быть множество применений, всё это убираем в папочку calls — папки на битриксе любят.

Мне кажется, что начальство не вдохновилось. Битрикс — не для хорошей жизни, терпеть его надо. А не выдумывать вот это всё.

Картинка выше — моя иллюстрация к битриксу. Да, это мои впечатления. Я опишу, как её рисовала, в отдельной статье — если опрос покажет, что я понимаю сегодня, какие будут ответы через неделю. Итак: