Когда внутри комплексного компонента вызываются несколько включаемых областей, то при наведении курсора на комплексный компонент - сразу не ясно какая из них нужная:
В параметры компонента можно добавить дополнительный параметр, отвечающий за текст кнопки редактирования, а затем сделать что-то вроде:
Тогда сразу становится понятным, какая из включаемых областей за что отвечает в комплексном компоненте:
В параметры компонента можно добавить дополнительный параметр, отвечающий за текст кнопки редактирования, а затем сделать что-то вроде:
Тогда сразу становится понятным, какая из включаемых областей за что отвечает в комплексном компоненте:
Добавить глобальную настройку 404 ошибки для стандартных компонентов ядра в настройки сайта.
- Устанавливать статус 404;
- Показ специальной страницы;
- Страница для показа (по умолчанию /404.php).
- Устанавливать статус 404;
- Показ специальной страницы;
- Страница для показа (по умолчанию /404.php).
При разработке своих компонентов или шаблонов на основе каких-то базовых приходится часто добавлять параметры (компонента или шаблона).
Добавление таких параметров в файл .parameters.php занимает определенное время особенно с учетом добавления описания даже на одном языке. Но, если этого не делать, а задавать значения новых параметров напрямую через вызов компонента, то приходится уже избегать редактирования параметров компонента через графический интерфейс, чтобы не затереть их. А если к настройке фронтэнда допущены другие лица, то вероятность случайного удаления этих параметров еще больше.
Было бы лучше, если бы такие неуказанные в .parameters.php параметры выводились в графическом режиме редактирования параметров компонента отдельным списком типа "Неуказанные параметры" в виде пар Код => Значение и пересохранялись при сохранении. Ну и возможность их изменения и удаления через ГУИ из кода вызова будет кстати.
Добавление таких параметров в файл .parameters.php занимает определенное время особенно с учетом добавления описания даже на одном языке. Но, если этого не делать, а задавать значения новых параметров напрямую через вызов компонента, то приходится уже избегать редактирования параметров компонента через графический интерфейс, чтобы не затереть их. А если к настройке фронтэнда допущены другие лица, то вероятность случайного удаления этих параметров еще больше.
Было бы лучше, если бы такие неуказанные в .parameters.php параметры выводились в графическом режиме редактирования параметров компонента отдельным списком типа "Неуказанные параметры" в виде пар Код => Значение и пересохранялись при сохранении. Ну и возможность их изменения и удаления через ГУИ из кода вызова будет кстати.
При подключении компонента namespace:componentname, искать его в следующих каталогах, взять первый найденный:
Например, код
подключит компонент, находящийся в каталоге
Зачем это нужно?
В будущем можно реализовать аналогичные функции для CSS/JS/расширений UI-библиотеки и пр.
- <docroot>/local/components/namespace/componentname
- <docroot>/bitrix/components/namespace/componentname
- Если ModuleManager::isModuleInstalled('namespace'):
- <docroot>/local/modules/namespace/components/componentname
- <docroot>/bitrix/modules/namespace/components/componentname
Например, код
$APPLICATION->IncludeComponent( 'partner.module:component.name', '' ); |
<docroot>/local/modules/partner.module/components/component.name |
Зачем это нужно?
- Партнеры смогут тратить меньше сил на создание установщиков (не нужно копировать файлы).
- Партнерам проще деплоить (устанавливать и обновлять) кастомные модули, которые не распространяются через Маркетплейс.
В будущем можно реализовать аналогичные функции для CSS/JS/расширений UI-библиотеки и пр.
Компонент корзина(sale.basket.basket) написан край как неудачно! И не только он...
В js идет построение верстки, но mvc и шаблонное проектирование вообще против такой парадигмы программирования! js должно только менять значения, а не конструировать верстку. Для js можно оставлять id в верстке и их же передавать массивом в js для дальнейшей работы с данными.
Сейчас же, для банальной стилизации компонента приходится его переписывать почти на половину!
Предлагаю разработчикам пересмотреть стиль написания стандартных шаблонов, для уменьшения стоимости работы по персонализации их CMS, а соответственно и увеличения популярности для конечных клиентов!
p.s. там же, в sale.basket.basket/class.php видел строки ужаса, где ресайзят картинки! в ЯДРЕ компонента, РЕСАЙЗ картинок, и только на 110x110px!
В js идет построение верстки, но mvc и шаблонное проектирование вообще против такой парадигмы программирования! js должно только менять значения, а не конструировать верстку. Для js можно оставлять id в верстке и их же передавать массивом в js для дальнейшей работы с данными.
Сейчас же, для банальной стилизации компонента приходится его переписывать почти на половину!
Предлагаю разработчикам пересмотреть стиль написания стандартных шаблонов, для уменьшения стоимости работы по персонализации их CMS, а соответственно и увеличения популярности для конечных клиентов!
p.s. там же, в sale.basket.basket/class.php видел строки ужаса, где ресайзят картинки! в ЯДРЕ компонента, РЕСАЙЗ картинок, и только на 110x110px!
Простейшая штука, а так была бы полезна.
В коде компонента вывода списка элементов (например, catalog.section), в месте, где происходит обращение к БД на выборку элементов, сливаются воедино два фильтра - тот, что задан в коде компонента, и внешний, который может быть задан разработчиком без влезания в код.
Сейчас это выглядит так:
$arrFilter - это преднастроенный в коде компонента фильтр.
Такая последовательность (ввиду логики работы array_merge) не позволяет переопределять параметры фильтрации, заложенные в коде компонента. Они всегда будут перезаписывать то, что пришло извне!
Особенно это обидно, когда нужно вывести стандартным компонентом неактивные элементы. Фактически - это сейчас сделать невозможно, надо копировать компонент, делать его кастомным, лишаться обновлений и т.д. И все ради простейшей задачи.
А дело-то всего лишь в последовательности переменных...
В коде компонента вывода списка элементов (например, catalog.section), в месте, где происходит обращение к БД на выборку элементов, сливаются воедино два фильтра - тот, что задан в коде компонента, и внешний, который может быть задан разработчиком без влезания в код.
Сейчас это выглядит так:
array_merge($arrFilter, $arFilter) |
Такая последовательность (ввиду логики работы array_merge) не позволяет переопределять параметры фильтрации, заложенные в коде компонента. Они всегда будут перезаписывать то, что пришло извне!
Особенно это обидно, когда нужно вывести стандартным компонентом неактивные элементы. Фактически - это сейчас сделать невозможно, надо копировать компонент, делать его кастомным, лишаться обновлений и т.д. И все ради простейшей задачи.
А дело-то всего лишь в последовательности переменных...
А почему до сих пор не реализованы опции для товара в стандартном функционале? Даже в joomshoping'е есть, а у нас битрикс все таки. Считаю необходимым внедрение функционала дополнительных опций (как в шаблоне битроник) в поставку стандартного ИМ начиная с редакции малый бизнес.
Если в построении URL используется #SECTION_CODE_PATH#, то компонент bitrix:catalog.section.list начинает генерировать ОЧЕНЬ большое количество запросов.
например, при выводе списка из 40 разделов, генерируется 176 запросов.
Если разделов много, то может быть и 1000 запросов.
Необходимо сделать кеширование URL к разделу (по примеру фасетного индекса для умного фильтра) и брать закешированные данные.
например, при выводе списка из 40 разделов, генерируется 176 запросов.
Если разделов много, то может быть и 1000 запросов.
Необходимо сделать кеширование URL к разделу (по примеру фасетного индекса для умного фильтра) и брать закешированные данные.
)Нынешний визредактор во многом уступает старому. В частности при выборе компонента приходится ориентироваться только на его русскоязычное название. Идентификатор компонента нельзя увидеть ни при наведении курсора, ни при нажатии на компонент в правом меню. Приходится располагать компонент в рабочем поле и смотреть настройки.
То же с поиском. Если я нашёл в документации компонент (условно говоря bitrix:sale.personal.section), я его никак не найду в списке компонентов.
Сейчас нигде не выводится краткое описание компонента, кроме настроек. Хотя это описание в первую очередь нужно для выбора компонента, потом оно уже не нужно.
Предлагаемые изменения:
То же с поиском. Если я нашёл в документации компонент (условно говоря bitrix:sale.personal.section), я его никак не найду в списке компонентов.
Сейчас нигде не выводится краткое описание компонента, кроме настроек. Хотя это описание в первую очередь нужно для выбора компонента, потом оно уже не нужно.
Предлагаемые изменения:
- выводить название компонента в подсказке при наведении курсора на иконку компонента (как в меню, так и в рабочем поле визуального редактора)
- то же, но при нажатии на компонент. где-то внизу должно выводиться название
- описание должно появляться во всплывающей подсказке
- в поиске компонентов поиск должен идти также по идентификаторам
Почему бы не добавить в компонент map.google.view возможность вставки json стилей для разукрашивания карт?
В поставке Битрикс24 очень много компонентов и частей системы, которые могут помочь, но они очень неюзабельный со стороны других разработчиков.
Пример 1: нет компонента привязки к сущности crm. Да можно вывернуться через system.field.edit, но корявенько получается.
Пример 2: есть компонент выбора пользователя и даже intranet.user.selector.new, но на практике просто взять и использовать нельзя, потому как он требует еще немножко магии
Какие части системы хотелось бы видеть в качестве штатных компонентов:
1) Компонент выбора сотрудников/подразделений. Тут все просто - по аналогии с "набором тегов" в ленте (с красивым выпадающим окошком) выбрать из структуры, найти из экстранет пользователей, выбрать группы и т.п.
Важно сразу учесть несколько моментов:
- Нужно иметь возможность не учитывать права доступа (т.е. выбирать всех пользователей экстранет)
- Давать возможность выбора только определенных сущностей (например только подразделения, только группы, только внешних пользователей)
А на выходе в нужную REQUEST-переменну клал массив по аналогии с лентой (например U1, SG202 и т.п.)
2) Компонент выбора сущности CRM (опять же с возможностью отключения прав доступа)
Это не полный список, но уже качественно улучшит качество разрабатываемых решений (во-первых единый интерфейс, а во-вторых не надо будет костылить с select2 и подобными) и одновременно увеличит скорость разработки (не надо будет писать с 0, когда есть уже готовое)
Пример 1: нет компонента привязки к сущности crm. Да можно вывернуться через system.field.edit, но корявенько получается.
Пример 2: есть компонент выбора пользователя и даже intranet.user.selector.new, но на практике просто взять и использовать нельзя, потому как он требует еще немножко магии
Какие части системы хотелось бы видеть в качестве штатных компонентов:
1) Компонент выбора сотрудников/подразделений. Тут все просто - по аналогии с "набором тегов" в ленте (с красивым выпадающим окошком) выбрать из структуры, найти из экстранет пользователей, выбрать группы и т.п.
Важно сразу учесть несколько моментов:
- Нужно иметь возможность не учитывать права доступа (т.е. выбирать всех пользователей экстранет)
- Давать возможность выбора только определенных сущностей (например только подразделения, только группы, только внешних пользователей)
А на выходе в нужную REQUEST-переменну клал массив по аналогии с лентой (например U1, SG202 и т.п.)
2) Компонент выбора сущности CRM (опять же с возможностью отключения прав доступа)
Это не полный список, но уже качественно улучшит качество разрабатываемых решений (во-первых единый интерфейс, а во-вторых не надо будет костылить с select2 и подобными) и одновременно увеличит скорость разработки (не надо будет писать с 0, когда есть уже готовое)
Добрый день.
Возник момент с кастомным кешированием в своем компоненте.
Согласно этому курсу (), подключение шаблона можно размещать как в кешируемой области, так и вне её.
При подключении шаблона в кешируемой области собственного компонента со сложным кешированием шаблон не отрабатывает вообще - сразу выводится html-кеш.
Разница в том, что в стандартных компонентах используется метод StartResultCache и при этом template.php кешируется полностью и выводится как html-кеш. При этом из кеша на хите достаются переменные VARS из файла кеша и передаются в component_epilog.php, что не происходит, если строить свое кеширование согласно вышеуказанному курсу.
Покопавшись в исходниках, выяснил, что в метод startResultCache() вшит также метод includeComponentEpilog(), которого нет в классах кастомного кеширования и в документации.
При этом входящие данные для него от родительского компонента в своем дочернем компоненте получить нельзя, так как свойство, в котором хранится путь и данные для метода includeComponentEpilog() лежат в родительском свойстве __component_epilog, которое имеет модификатор доступа private и недоступен в потомке.
В связи с этим кастомное кеширование получается неполноценным, т.к. для использования в шаблонах component_epilog, нужно подключение шаблона обязательно выводить из кешируемой области.
Прошу дать возможность разработчику самостоятельно подключать эпилог компонента в своем компоненте.
Возник момент с кастомным кешированием в своем компоненте.
Согласно этому курсу (), подключение шаблона можно размещать как в кешируемой области, так и вне её.
При подключении шаблона в кешируемой области собственного компонента со сложным кешированием шаблон не отрабатывает вообще - сразу выводится html-кеш.
Разница в том, что в стандартных компонентах используется метод StartResultCache и при этом template.php кешируется полностью и выводится как html-кеш. При этом из кеша на хите достаются переменные VARS из файла кеша и передаются в component_epilog.php, что не происходит, если строить свое кеширование согласно вышеуказанному курсу.
Покопавшись в исходниках, выяснил, что в метод startResultCache() вшит также метод includeComponentEpilog(), которого нет в классах кастомного кеширования и в документации.
При этом входящие данные для него от родительского компонента в своем дочернем компоненте получить нельзя, так как свойство, в котором хранится путь и данные для метода includeComponentEpilog() лежат в родительском свойстве __component_epilog, которое имеет модификатор доступа private и недоступен в потомке.
В связи с этим кастомное кеширование получается неполноценным, т.к. для использования в шаблонах component_epilog, нужно подключение шаблона обязательно выводить из кешируемой области.
Прошу дать возможность разработчику самостоятельно подключать эпилог компонента в своем компоненте.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
