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