В этой статье речь пойдёт о некотором моём предложении для сообщества. Это вдвойне сомнительное предложение из-за того, что мой личный трип на битриксе уже закончился. Две недели безвылазно на учёбе плюс где-то неделя в ритме "пытаюсь себя заставить" и... И вот статья. Держите. Надеюсь, кому-нибудь пригодится.
Как пишутся компоненты сегодня
Вы создаёте папку в пространстве имён внутри вашей папки 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 - папки в битриксе любят.
Мне кажется, что начальство не вдохновилось. Битрикс - не для хорошей жизни, терпеть его надо. А не выдумывать вот это всё.
Картинка выше - моя иллюстрация к битриксу. Да, это мои впечатления. Я опишу, как её рисовала, в отдельной статье - если опрос покажет, что я понимаю сегодня, какие будут ответы через неделю. Итак:
Комментарии (14)
den_rad
29.08.2022 00:18А как сейчас с поддержкой composer и PSR-4 в Битриксе? В Wordpress, как я видел, некоторые плагины тянут каждый свой composer autoload, что меня сильно удивило :(
Nasreddin_Hodja
Визуальным редактором не обязательно пользоваться. По задумке он для вебмастеров, которые не занимаются программированием, а у них есть CMS и они всё делают через её админку.
MaryRabinovich Автор
А как вы обычно вставляете компоненты в вёрстку? Если ещё не использовали их в той же вёрстке где-то ещё? Если уже использовали, понятное дело, можно найти готовые куски кода прямо внутри проекта (то, что заранее бы предоставлялось файлом example_call.php).
На академии битрикса выдан именно этот способ, через админку с кнопками и копированием.
Я для себя нашла более удобный (сравнительно щадящий способ) для стандартных компонентов - копировать код из документации к ним. Но для кастомных так не получится, к ним нет подробной документации.
Nasreddin_Hodja
Да.
Смотря чей кастом. Да и в битриксе и так приходится нередко в код ядра заглядывать чтобы понять как он должен работать, документация не всё покрывает.
А в случае когда приходится использовать на разных страницах один и тот же компонент, но с разными шаблонами или с изменёнными парой параметров, то вместо копирования простыни параметров размещаю их в одном месте и просто переиспользую эти параметры. Да, это ломает редактирование параметров компонента из визуального редактора, но зачастую не предполагается что какой-то контент-менеджер будет вообще лезть что-то там править.
Ну, вариант с редактированием компонента на тестовой странице и последующим копированием кода компонента оттуда куда надо тоже ок, кому как удобнее.
MaryRabinovich Автор
А появление calls/example_call.php в папочке компонента разом бы всё это упростило. Я пробовала. Просто копируете всё в одно действие, стираете всё ненужное, дальше эти вот подключения делаете из example_call.php обыденной копи-пастой на файлах.
MaryRabinovich Автор
(ещё раз обдумав)
Верно ли я понимаю, что вы про тот факт, что если вы из одного и того же файла делаете подключение компонента в разных местах, то правка параметров в одном месте ломает вид для другого места?
Если вы именно об этом, то я как раз веду речь о папке для вызовов. Это может быть, например, подпапка папки local/components/. Изнутри у local/components/ отдельные отсеки для разных компонентов. Ну и вот в каждый отсек, помимо шаблонов и других мелочей, можно добавить подпапку calls/ соответствующего компонента. Дальше внутри этой папки либо будут файлы с осмысленными названиями, типа footer_call.php (если заранее ясно, что в футере вызовем точно только единожды) и др., либо просто call1.php, call2.php...
ЗЫ это, казалось бы, вообще не выглядит как вопрос для решения. Проблема лишь в том, что любое действие, которое требуется выполнять регулярно, либо глобально отрефлексировано и автопилотизируется, либо делается каждый раз с нуля.
Nasreddin_Hodja
Не совсем. Допустим, у нас есть несколько страниц, где нужно вывести компонент, например
bitrix:catalog.sectionс почти теми же настройками, но с разными кастомными шаблонами, либо просто с разными фильтрами. Сам компонент стандартный, не модифицированный, модифицировался только его шаблон.И вот вместо того чтобы копировать одну и ту же простыню параметров этого компонента, можно массив параметров описать в каком нибудь файле
local/components/.conf/configname.php, написать функциюgetComponentConf(string $name, array $paramsToOverrride = []), которая при вызовеgetComponentConf('configname')подключает внутри себя соответствующий файл и возвращает массив, который и подставляется вincludeComponent('bitrix:catalog.section', 'mytemplate', getComponentConf('configname')).Но визуальный редактор параметров компонента это не любит и при попытке его отредактировать выдаёт ошибку. Но обычно это не проблема, т.к. туда что-то редактировать зачастую никто не лезет.
MaryRabinovich Автор
Проблема с таким решением в его, как бы сказать... оно слишком умное. Кругом лапшекод, а вы подключаете геттер.
Моё решение глупое - честно сказать, в этом-то и состояла трудность. Сделать решение, вписывающееся стилистикой в это вот всё. Оно НЕ ломается - его с удовольствием редактирует визуальный редактор. При этом и вёрстка чистая (в неё вставлена только строчка с require файл), и сам этот файл, который мы подключаем, в нём вызов функции IncludeComponent, с названием компонента, шаблона, и массивом параметров.
Если договориться, что всё это в одной папке (допустим, для компонента bitrix:catalog.section это local/templates/current_template/components/bitrix/catalog.section/calls/ ), то для создания нескольких файлов с примерно одними параметрами просто копируем мышкой. Причём внутри папки. Причём из исходника example_call.php, где всё уже в целом есть.
Тут основное, что я предлагаю вынос в отдельный файл всего вызова. Именно поэтому визуальный редактор справляется с моей конструкцией. Вы реально выносите формирование параметров. Да ещё оборачиваете это функцией. Конечно, от этого часть исходного функционала теряется - он же вообще не особо с функциями. Кажется. Кажется, либо там сразу классы (и методы классов), либо инклуд лапшекод.
TigerClaw
Ну я просто копирую из своих же старых проектов. Все про большей части я использую либо битриксовые компоненты или компоненты уж созданные. Ну а если с нуля, то делаю их на отдельной странице. Честно забыл уже когда последний раз вставлял компоненты через визуальный редактор. Да и компоненты в большинстве случаев даже вставляю с уже близкими по функционалу шаблонами.
MaryRabinovich Автор
А есть ли у вас привычный способ, где именно расположить этот выносной файл? И как называть? И если один компонент у вас подключается сразу в несколько мест, делаете ли вы сразу несколько выносных файлов в одной общей папке? А как вы её называете, и как называете файлы внутри неё?
И, конечно, вопрос, как именно вы начинаете использование нового компонента. Вызов которого в данный момент у вас в коде отсутствует.
Есть ли какой-нибудь третий способ, помимо стандартных
сделать первый раз через визуальный редактор
выйти в сеть, зайти на документацию, скопировать оттуда вызов... если он предоставлен, конечно
И сколько времени всё это занимает - в том числе, на переключение внимания. Какая лично для вас возникла бы экономия времени, если бы вся эта деятельность перестала быть нужной, поскольку уже изначально в папке компонента есть подпапка calls/ с файлом example_call.php?
Собственно, это вопрос о возможной мотивации для разработчиков делать именно так: окажется ли нововведение выгодным в человеко-часах (и нервах, конечно).
TigerClaw
Тут все зависит от ситуации. Как правило дублирование не требуется. А если и требуется то все что я инклужу я размещаю только в отдельной папке текущего шаблона, никаких левых папок в корне сайта. Мухи отдельно, а котлеты отдельно. Нейминг компонент от компании разработчика. Это все же уникальное имя. Что то вообще выношу в свои классы подключая через init.php. Тут тот же принцип в нейминге. Да битрикс из-за древнего наследия имеет очень много костылей от которых сейчас не так просто отказаться.
Да бывает ситуация когда требуется несколько шаблонов на проекте в силу его особенностей. Ну тогда это .default. Но если возможно я предпочитаю не использовать несколько шаблонов, программируя логику и требуя от верстальщика логичности верстки и ее единообразия.
ssv32
теоретически можно решать на уровне IDE. Т.е. делаете "шаблон кода" (не помню как это в общем называется в моей IDE так), например на часто используемые компоненты, например пишите слово news, нажимаете ентер и вставляется вся партянка параметров (если она нужна конечно), сами её добавляете можно с комментариями. Но тут будут проблемы, актуализацыя, и сделать первоначально такое время займёт.
MaryRabinovich Автор
Кажется, вы про сниппеты.
Правда, сниппеты надо же самому завести сначала. Чтобы сниппетом пользоваться, надо его оформить.
(заводит шарманку) а вот если бы стало принято складывать файл example_call.php в подпапку calls/ при создании папочки компонента...
(выключает шарманку) послушала тут внезапно Сергея Рыжикова. Каакой у него аккуратный вкрадчивый голос! Да в списке Форбс по России. Ууу, если уж микрософт мастдай, то тут - вообще не вопрос. Если бы с этим маркетингом поперёк разработчиков были тысячными в списке Форбс, я поняла бы. Но чтобы так вот, будучи при этом в десятке... ууу!
Подозреваю, что Тейлор (Отвелл) тоже не бедный. Но всё таки.
ssv32
Если речь про стандартные компоненты, вся простыня параметров и не нужна может быть, надо смотреть док и например ставить параметры только те которые нужны (большинство по умолчанию имеют значение).
(По началу также через визуальный редактор искал нужные компоненты, параметры, но потом всё свилось к тому что большинство используемых компонентов уже известны и ищешь чисто по документации конкретное)
Про кастомные компоненты, тут всё на совести того кто делал, может оставить описание параметров, а может вообще не быть, тогда только в код смотреть.
Компоненты написанные с нуля, обычно там мало параметров, т.к. не делаются супер гибкими и под разные настройки как стандартные битриксовые, а делаются под конкретную задачу (если компонент не для маркетплейса).
(Т.е. в свой компонент прокинул время кеша, инфоблок, может ещё что то и всё, нет кучи параметров для большей настройки если она не нужна)
(конечно возможно это чисто от моего опыта и где то кастомные компоненты пишут с кучей параметров, тогда по хорошему нужно описание всего)