Рейтинг: 2.8902  
Новая
Предложил Турунов Михаил 03.08.2019 09:13:09

Списки, таблицы, параметры. Представление

В разных местах по разному!
Не удобно.

-почта. https://prnt.sc/onrg3o  нет шестеренки, нет сортировки
-срм. https://prnt.sc/onrgfz непо всем полям возможна сортировка
-список исключений. https://prnt.sc/onrgrt  мало полей
-он же https://prnt.sc/onrh2k  нет выбора количества элементов на странице, мало груповых действий
-где есть выбор количества элементов https://prnt.sc/onrhf9  нет параметров 200, 500 как в 1С:Битрикс


Хорошо бы чтобы все было в одном стандарте.
Рейтинг: 2  
Новая
Предложил Удовиченко Юрий 15.11.2018 07:21:48

Добавлять группы параметров в шаблоне компонента

Есть раздел документации "Параметры компонента" https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=43&LESSON_ID=2132 в котором до сих пор ничего не говорится о возможности добавлять дополнительную переменную $arComponentParameters для добавления параметров шаблона.

Но самое печальное из шаблона нет возможности добавить дополнительную группу для отображения таких параметров. На практике часто необходимо выделить их в отдельный блок, который, к тому же,  желательно отобразить на самом верху управления.

Поэтому предлагаю:
1. Добавить описание переменной $arComponentParameters в документацию
2. Создать возможность добавления групп параметров из шаблона (Я уже не говорю о переопределении, а хотя бы добавление).
Рейтинг: 2.1453  
На голосовании
Предложил Ерофеев Анатолий 05.06.2015 10:15:17

Частичное обновление профиля пользователя

Компонент профиль пользователя (main.profile) всегда обновляет пользователя целиком. Он каждый раз ожидает, что в $_REQUEST к нему придут EMAIL, LOGIN, NAME и все остальные обычные поля.

Получается, если мы хотим дать пользователю редактировать только, например, пароль, то все остальные поля нужно выводить в hidden-инпутах. Это неудобно и небезопасно - пользователь может подделать значения hidden полей и всё-таки обновить скрытые поля (поля обычно скрыты если не используются или содержат служебную информацию).

Предлагаю добавить в компонент настройку - какие именно поля разрешать редактировать, выводить в стандартном шаблоне только их и вытаскивать из $_REQUEST только их.
Рейтинг: 0.239  
На голосовании
Предложил Марцуль Владимир 25.03.2015 12:58:20

Убрать параметр в ссылках на css и js

Наличие любого параметра (?blablabla) у ссылки на подключаемый файл заставляет любое клиентское приложение (браузер, прокси-сервер, мобильное приложение и т.д.) обязательно обратиться за файлом на сервер.
Это RFC.
Сервер, в лучшем случае ответит "304 Not Modified" (но при этом всё равно дёрнет файл с диска/памяти, чтобы проверить) или же полноценный 200 с полной передачей файла.
Ответ сервера в некоторых кешах сохранится, в некоторых (н-р, AppCache) нет.

Соответственно, время модификации, хеш от него или любой другой праметр для cache busting должен быть в имени или пути файла (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b-142712022549372.js), а не в параметре (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b.js?142712022549372).

Проверить очень просто: при повторном открытии страницы сайта на сервер должен идти только 1 запрос - на саму страницу, а все остальные файлы должны браться из кеша браузера.

UPDATE 2015-04-01

Теоретическое обоснование и рекомендации от известных разработчиков:
Реализации:
Первые попашиеся "правильные" сайты:
Font-Awesome планирует в 5-й версии перенести параметр в название файла шрифта https://github.com/FortAwesome/Font-Awesome/issues/5231 и https://github.com/FortAwesome/Font-Awesome/issues/3286
Рейтинг: 7.4395  
На голосовании
Предложил Прокофьев Андрей 06.07.2014 23:53:05

Добавить параметр «Композитный режим» к компонентам

Сейчас, для того чтобы заставить страницу работать в композитном режиме нужно, как минимум, залезть в шаблон каждого компонента и добавить строчку

$this->setFrameMode(false);

Когда таких компонентов много — процесс затягивается... А бывает , что просто приходится умышленно копировать какой-нибудь bitrix:socserv.auth.form к себе в шаблон сайта, ради того, чтобы всё остальное заработало...

Слишком много лишних действий. Можно и нужно сделать проще...

Например, ко всем компонентам добавить параметр a la "CACHE_TYPE":
"COMPOSITE" => "ALLOW" | "USE" | "SELF" | "DENY"
И рассмотреть возможные кейсы:
  1. Компонент «разрешает» работать остальным;
  2. Компонент сам работает в композитном режиме*;
  3. На усмотрение разработчика (разработчик сам правит шаблон компонента и расставляет динамические/статические области);
  4. Компонент запрещает «всё и всем»;
*Предполагает, что система сама оборачивает шаблон компонента в:
$this->setFrameMode(false);
$frame = $this->createFrame()->begin(); 

/*Код шаблона компонента*/ 
 

$frame->end();

 
Рейтинг: 2.9659  
На голосовании
Предложил Шерлок Холмс 30.05.2014 10:07:04

Сделать макрос #SITE_DIR# доступным в шаблонах путей всех компонентов

Сейчас он доступен, только в bitrix:search.form:





это удобно, если форма размещается в шаблоне, который используется на нескольких сайтах (например, при нескольких языковых версиях).

В других компонентах (например, bitrix:sale.basket.line или bitrix:catalog он не доступен).
Рейтинг: 3.1304  
На голосовании
Предложил Шерлок Холмс 16.05.2014 17:26:02

В компоненте bitrix:catalog.section.list добавить параметры навигации

Добавить в компонент bitrix:catalog.section.list возможность указать в параметрах максимлаьное число выбираемых разделов (например, я хочу вывести первые 10 разделов первого уровня), и возможность задавать параметры постраничной навигации.

Так же хорошо бы реализовать идею с фильтрацией в компоненте bitrix:catalog.section.list
http://idea.1c-bitrix.ru/in-the-component-bitrixcatalogsectionlist-add-support-filter/
Рейтинг: -2.123  
На голосовании
Предложил Шерлок Холмс 28.03.2014 17:53:42

Права на изменение только определенных параметров компонента

Предлагаю добавить права на доступ к редактированию параметров компонента для групп пользователей.

Чтобы дать доступ, например, группе "контент-менеджер" редактировать только определенные параметры компонента (а не все сразу).

Давать редактировать абсолютно все параметры компонента - может быть опасно, кто-то случайно поменяет шаблон или настройки путей, и все перестает работать.

Если оставить групе права менять только менее значащие параметры (настройки постраничной навигации, цветовую схему, количество элементов на странице или настройки вывода свойств), то будет намнго удобнее и безопаснее.
Рейтинг: 0  
Внедрено
Предложил Шерлок Холмс 16.03.2014 23:56:53

Поддержка параметра REFRESH=>"Y" для свойств с типом Список

Добавить поддержку параметра REFRESH => "Y" в настройках параметров компонента (.parameters.php) для свойств с типом "Список" (LIST).
Рейтинг: 0  
Ответил Жуков Евгений 17.03.2014 11:43:31
Этот ключ поддерживается для списков минимум с 5-й версии.
Рейтинг: 2.3301  
На голосовании
Предложил Шерлок Холмс 26.02.2014 18:34:11

Выбор раздела в виде выпадаюещго списка (bitrix:catalog.section)

В компоненте bitrix:catalog.section в настройках параметров поле для выбора раздела сделать в виде выпадающего списка разделов выбранного инфоблока:


При этом, возможность ввода дополнительных значений желательно оставить.
Рейтинг: 17.3539  
На голосовании
Предложил Шерлок Холмс 17.02.2014 21:35:27

Событие при построении списка параметров компонента

Добавить событие при построении дерева параметров компонента (чтобы можно было модифицировать параметры стандартных компоненов).
Рейтинг: 3.5064  
На голосовании
Предложил Ерофеев Анатолий 09.01.2014 10:17:29

Страница входа (для системных компонентов)

В главном модуле есть такая настройка "Страница регистрации (для системного компонента авторизации)". Т.е. в настройках компонента в публичной части сайта можно не указывать путь к странице регистрации и тогда этот путь будет взят из этой настройки. Логично, удобно - регистрация-то на сайте одна, а ссылки на нее могут быть в десятках мест.

Предлагаю сделать настройки аналогичного вида для страницы входа, страницы запроса на восстановление пароля, самой страницы восстановления пароля, подтверждения регистрации. Компоненты ничего не потеряют - просто, если эти настройки указаны в модуле, он будет брать их оттуда, если нет - то все будет работать по старому.
Рейтинг: 3.6865  
На голосовании
Предложил Ерофеев Анатолий 16.12.2013 10:29:49

Ввести событие "перед отображением параметров в окне настройки компонента"

Вспомните компонент iblock.element.add.form, который сохраняет только те свойства, которые указаны в настройках. А так же вспомните, что он позволяет выбрать только простые поля, а вот привязку к элементам инфоблока, например, не умеет. Чтобы разрешить эту проблему каждый раз приходится его кастомизировать и добавлять в список нужный вам тип полей.
Мне могут возразить - есть же параметры шаблонов, туда можно добавить все, что угодно! Да, можно, но только добавить, а не изменить.
Если бы такое событие было, то можно бы создать обработчик события, и для компонента iblock.element.add.form для всех шаблонов разом добавить поддержку новых типов данных.

P.S. Поможет в реализации идеи http://idea.1c-bitrix.ru/ability-to-hide-the-component-settings-when-you-configure/
Рейтинг: 52.1513  
На голосовании
Предложил Шерлок Холмс 29.09.2013 02:18:10

Возможность скрывать параметры в стандартных компонентах

Мы можем добавлять свои параметры для стандартных компонентов с помощью файла .parameters.php в шаблоне компонента, но нехватает еще одной важной штуки - возможности убирать некрторые стандартные параметры (и переименовывать тоже было бы хорошо).

Например, я использую компонент bitrix:catalog, и потом отдаю его в продакшен под управление клиенту, но мне нужно скрыть из него ненужные параметры, чтобы не навредить (например, настройки ЧПУ, которые всё равно дублируются в инфоблоке, или типы цен). И оставить только самое нужное (например, кол-во элементов на странице, параметры сортировки, выбираемые свойства, и еще пару мелочей).



Зачем клиенту лицезреть эту простыню из стандартных параметров, 90% из которых задаются один раз, разработчиком, и лучше чтобы он их менял, а контент-менежер или клиент - их не видели, и если нужно - могли менять через код (или галочку "показать все настройки";).
Рейтинг: 16.2527  
Новая
Предложил Ерофеев Анатолий 12.07.2013 08:26:04

Возможность скрывать некоторые параметры компонента при настройке

Многие любопытные клиенты с шаловливыми ручонками любят залезть в визуальном редакторе в настройки компонентов и что-нибудь там пощелкать. То есть хотелось бы иметь возможность скрывать параметры компонентов. Каким образом? Скажем, в файле .parameters.php шаблона компонента указывать (при программировании сайта), какие настройки оригинального компонента скрывать при редактировании с лица.

То есть, чтобы пользователь мог открыть параметры компонента, но отображались ему не все поля, а только те, которые мы ему оставим. Честно говоря, это полезно было бы и при разработке для программистов - когда компонент имеет несколько десятков параметров, становится сложно ориентироваться. А если бы механизм существовал - можно было бы скрыть те параметры, которые уже не будут меняться.

Пример 1:
на странице каталога размещен комплексный каталог и ID инфоблока не будет меняться никогда с вероятностью 90%, а клиенту это вообще не нужно в 100% случаев - так и нужно дать возможность скрыть эту настройку.
Настройки ЧПУ, кеширования - тоже избыточны для клиента. Оставим ему списки полей, какие где выводятся - и этого будет достаточно.

Пример 2 (VCS):
В проектах с git'ом или любой другой VCS в параметры компонента обычно передаются не ID'шники (которые могут быть различными на dev, stage и prod-серверах), а что-то вроде getIblockIdByCode("news";). Скрыть такое от глаз неподготовленного человека тоже полезно.
Рейтинг: 22.6036  
Внедрено
Предложил Бойков Дмитрий 11.07.2012 12:22:45

Утверждение: требовать комментарий при отказе

Добавить в настройку activity  Утверждение документа дополнительный параметр требовать комментарий при отказе:



Соответственно при установке опции поле комментария становится обязательным к заполнению в случае отказа.

Это позволит сэкономить время затрачиваемое на выяснение причин отказа по телефону или электронной почте.