В разных местах по разному!
Не удобно.
-почта. нет шестеренки, нет сортировки
-срм. непо всем полям возможна сортировка
-список исключений. мало полей
-он же нет выбора количества элементов на странице, мало груповых действий
-где есть выбор количества элементов нет параметров 200, 500 как в 1С:Битрикс
Хорошо бы чтобы все было в одном стандарте.
Не удобно.
-почта. нет шестеренки, нет сортировки
-срм. непо всем полям возможна сортировка
-список исключений. мало полей
-он же нет выбора количества элементов на странице, мало груповых действий
-где есть выбор количества элементов нет параметров 200, 500 как в 1С:Битрикс
Хорошо бы чтобы все было в одном стандарте.
Есть раздел документации "Параметры компонента" в котором до сих пор ничего не говорится о возможности добавлять дополнительную переменную $arComponentParameters для добавления параметров шаблона.
Но самое печальное из шаблона нет возможности добавить дополнительную группу для отображения таких параметров. На практике часто необходимо выделить их в отдельный блок, который, к тому же, желательно отобразить на самом верху управления.
Поэтому предлагаю:
1. Добавить описание переменной $arComponentParameters в документацию
2. Создать возможность добавления групп параметров из шаблона (Я уже не говорю о переопределении, а хотя бы добавление).
Но самое печальное из шаблона нет возможности добавить дополнительную группу для отображения таких параметров. На практике часто необходимо выделить их в отдельный блок, который, к тому же, желательно отобразить на самом верху управления.
Поэтому предлагаю:
1. Добавить описание переменной $arComponentParameters в документацию
2. Создать возможность добавления групп параметров из шаблона (Я уже не говорю о переопределении, а хотя бы добавление).
Компонент профиль пользователя (main.profile) всегда обновляет пользователя целиком. Он каждый раз ожидает, что в $_REQUEST к нему придут EMAIL, LOGIN, NAME и все остальные обычные поля.
Получается, если мы хотим дать пользователю редактировать только, например, пароль, то все остальные поля нужно выводить в hidden-инпутах. Это неудобно и небезопасно - пользователь может подделать значения hidden полей и всё-таки обновить скрытые поля (поля обычно скрыты если не используются или содержат служебную информацию).
Предлагаю добавить в компонент настройку - какие именно поля разрешать редактировать, выводить в стандартном шаблоне только их и вытаскивать из $_REQUEST только их.
Получается, если мы хотим дать пользователю редактировать только, например, пароль, то все остальные поля нужно выводить в hidden-инпутах. Это неудобно и небезопасно - пользователь может подделать значения hidden полей и всё-таки обновить скрытые поля (поля обычно скрыты если не используются или содержат служебную информацию).
Предлагаю добавить в компонент настройку - какие именно поля разрешать редактировать, выводить в стандартном шаблоне только их и вытаскивать из $_REQUEST только их.
Наличие любого параметра (?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
Теоретическое обоснование и рекомендации от известных разработчиков:
Это 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
Теоретическое обоснование и рекомендации от известных разработчиков:
- Application cache
Never access cached files by using traditional GET parameters (like other-cached-page.html?parameterName=value). This will make the browser bypass the cache and attempt to get it from network.
- В Apache
- В Nginx
- Rails Asset Pipeline
- Модуль Web Optimizer для 1С-Битрикс, многие идеи из которого перешли "в коробку"
- Все проекты TM (.)
Сейчас, для того чтобы заставить страницу работать в композитном режиме нужно, как минимум, залезть в шаблон каждого компонента и добавить строчку
Когда таких компонентов много — процесс затягивается... А бывает , что просто приходится умышленно копировать какой-нибудь bitrix:socserv.auth.form к себе в шаблон сайта, ради того, чтобы всё остальное заработало...
Слишком много лишних действий. Можно и нужно сделать проще...
Например, ко всем компонентам добавить параметр a la "CACHE_TYPE":
"COMPOSITE" => "ALLOW" | "USE" | "SELF" | "DENY"
И рассмотреть возможные кейсы:
$this->setFrameMode(false); |
Когда таких компонентов много — процесс затягивается... А бывает , что просто приходится умышленно копировать какой-нибудь bitrix:socserv.auth.form к себе в шаблон сайта, ради того, чтобы всё остальное заработало...
Слишком много лишних действий. Можно и нужно сделать проще...
Например, ко всем компонентам добавить параметр a la "CACHE_TYPE":
"COMPOSITE" => "ALLOW" | "USE" | "SELF" | "DENY"
И рассмотреть возможные кейсы:
- Компонент «разрешает» работать остальным;
- Компонент сам работает в композитном режиме*;
- На усмотрение разработчика (разработчик сам правит шаблон компонента и расставляет динамические/статические области);
- Компонент запрещает «всё и всем»;
$this->setFrameMode(false); $frame = $this->createFrame()->begin(); /*Код шаблона компонента*/ $frame->end(); |
Сейчас он доступен, только в bitrix:search.form:
это удобно, если форма размещается в шаблоне, который используется на нескольких сайтах (например, при нескольких языковых версиях).
В других компонентах (например, bitrix:sale.basket.line или bitrix:catalog он не доступен).
это удобно, если форма размещается в шаблоне, который используется на нескольких сайтах (например, при нескольких языковых версиях).
В других компонентах (например, bitrix:sale.basket.line или bitrix:catalog он не доступен).
Добавить в компонент bitrix:catalog.section.list возможность указать в параметрах максимлаьное число выбираемых разделов (например, я хочу вывести первые 10 разделов первого уровня), и возможность задавать параметры постраничной навигации.
Так же хорошо бы реализовать идею с фильтрацией в компоненте bitrix:catalog.section.list
Так же хорошо бы реализовать идею с фильтрацией в компоненте bitrix:catalog.section.list
Предлагаю добавить права на доступ к редактированию параметров компонента для групп пользователей.
Чтобы дать доступ, например, группе "контент-менеджер" редактировать только определенные параметры компонента (а не все сразу).
Давать редактировать абсолютно все параметры компонента - может быть опасно, кто-то случайно поменяет шаблон или настройки путей, и все перестает работать.
Если оставить групе права менять только менее значащие параметры (настройки постраничной навигации, цветовую схему, количество элементов на странице или настройки вывода свойств), то будет намнго удобнее и безопаснее.
Чтобы дать доступ, например, группе "контент-менеджер" редактировать только определенные параметры компонента (а не все сразу).
Давать редактировать абсолютно все параметры компонента - может быть опасно, кто-то случайно поменяет шаблон или настройки путей, и все перестает работать.
Если оставить групе права менять только менее значащие параметры (настройки постраничной навигации, цветовую схему, количество элементов на странице или настройки вывода свойств), то будет намнго удобнее и безопаснее.
Добавить поддержку параметра REFRESH => "Y" в настройках параметров компонента (.parameters.php) для свойств с типом "Список" (LIST).
Ответил 
Жуков Евгений 17.03.2014 11:43:31
Жуков Евгений 17.03.2014 11:43:31
Этот ключ поддерживается для списков минимум с 5-й версии.
В компоненте bitrix:catalog.section в настройках параметров поле для выбора раздела сделать в виде выпадающего списка разделов выбранного инфоблока:
При этом, возможность ввода дополнительных значений желательно оставить.
При этом, возможность ввода дополнительных значений желательно оставить.
Добавить событие при построении дерева параметров компонента (чтобы можно было модифицировать параметры стандартных компоненов).
В главном модуле есть такая настройка "Страница регистрации (для системного компонента авторизации)". Т.е. в настройках компонента в публичной части сайта можно не указывать путь к странице регистрации и тогда этот путь будет взят из этой настройки. Логично, удобно - регистрация-то на сайте одна, а ссылки на нее могут быть в десятках мест.
Предлагаю сделать настройки аналогичного вида для страницы входа, страницы запроса на восстановление пароля, самой страницы восстановления пароля, подтверждения регистрации. Компоненты ничего не потеряют - просто, если эти настройки указаны в модуле, он будет брать их оттуда, если нет - то все будет работать по старому.
Предлагаю сделать настройки аналогичного вида для страницы входа, страницы запроса на восстановление пароля, самой страницы восстановления пароля, подтверждения регистрации. Компоненты ничего не потеряют - просто, если эти настройки указаны в модуле, он будет брать их оттуда, если нет - то все будет работать по старому.
Вспомните компонент iblock.element.add.form, который сохраняет только те свойства, которые указаны в настройках. А так же вспомните, что он позволяет выбрать только простые поля, а вот привязку к элементам инфоблока, например, не умеет. Чтобы разрешить эту проблему каждый раз приходится его кастомизировать и добавлять в список нужный вам тип полей.
Мне могут возразить - есть же параметры шаблонов, туда можно добавить все, что угодно! Да, можно, но только добавить, а не изменить.
Если бы такое событие было, то можно бы создать обработчик события, и для компонента iblock.element.add.form для всех шаблонов разом добавить поддержку новых типов данных.
P.S. Поможет в реализации идеи
Мне могут возразить - есть же параметры шаблонов, туда можно добавить все, что угодно! Да, можно, но только добавить, а не изменить.
Если бы такое событие было, то можно бы создать обработчик события, и для компонента iblock.element.add.form для всех шаблонов разом добавить поддержку новых типов данных.
P.S. Поможет в реализации идеи
Мы можем добавлять свои параметры для стандартных компонентов с помощью файла .parameters.php в шаблоне компонента, но нехватает еще одной важной штуки - возможности убирать некрторые стандартные параметры (и переименовывать тоже было бы хорошо).
Например, я использую компонент bitrix:catalog, и потом отдаю его в продакшен под управление клиенту, но мне нужно скрыть из него ненужные параметры, чтобы не навредить (например, настройки ЧПУ, которые всё равно дублируются в инфоблоке, или типы цен). И оставить только самое нужное (например, кол-во элементов на странице, параметры сортировки, выбираемые свойства, и еще пару мелочей).
Зачем клиенту лицезреть эту простыню из стандартных параметров, 90% из которых задаются один раз, разработчиком, и лучше чтобы он их менял, а контент-менежер или клиент - их не видели, и если нужно - могли менять через код (или галочку "показать все настройки";).
Например, я использую компонент bitrix:catalog, и потом отдаю его в продакшен под управление клиенту, но мне нужно скрыть из него ненужные параметры, чтобы не навредить (например, настройки ЧПУ, которые всё равно дублируются в инфоблоке, или типы цен). И оставить только самое нужное (например, кол-во элементов на странице, параметры сортировки, выбираемые свойства, и еще пару мелочей).
Зачем клиенту лицезреть эту простыню из стандартных параметров, 90% из которых задаются один раз, разработчиком, и лучше чтобы он их менял, а контент-менежер или клиент - их не видели, и если нужно - могли менять через код (или галочку "показать все настройки";).
Многие любопытные клиенты с шаловливыми ручонками любят залезть в визуальном редакторе в настройки компонентов и что-нибудь там пощелкать. То есть хотелось бы иметь возможность скрывать параметры компонентов. Каким образом? Скажем, в файле .parameters.php шаблона компонента указывать (при программировании сайта), какие настройки оригинального компонента скрывать при редактировании с лица.
То есть, чтобы пользователь мог открыть параметры компонента, но отображались ему не все поля, а только те, которые мы ему оставим. Честно говоря, это полезно было бы и при разработке для программистов - когда компонент имеет несколько десятков параметров, становится сложно ориентироваться. А если бы механизм существовал - можно было бы скрыть те параметры, которые уже не будут меняться.
Пример 1:
на странице каталога размещен комплексный каталог и ID инфоблока не будет меняться никогда с вероятностью 90%, а клиенту это вообще не нужно в 100% случаев - так и нужно дать возможность скрыть эту настройку.
Настройки ЧПУ, кеширования - тоже избыточны для клиента. Оставим ему списки полей, какие где выводятся - и этого будет достаточно.
Пример 2 (VCS):
В проектах с git'ом или любой другой VCS в параметры компонента обычно передаются не ID'шники (которые могут быть различными на dev, stage и prod-серверах), а что-то вроде getIblockIdByCode("news";). Скрыть такое от глаз неподготовленного человека тоже полезно.
То есть, чтобы пользователь мог открыть параметры компонента, но отображались ему не все поля, а только те, которые мы ему оставим. Честно говоря, это полезно было бы и при разработке для программистов - когда компонент имеет несколько десятков параметров, становится сложно ориентироваться. А если бы механизм существовал - можно было бы скрыть те параметры, которые уже не будут меняться.
Пример 1:
на странице каталога размещен комплексный каталог и ID инфоблока не будет меняться никогда с вероятностью 90%, а клиенту это вообще не нужно в 100% случаев - так и нужно дать возможность скрыть эту настройку.
Настройки ЧПУ, кеширования - тоже избыточны для клиента. Оставим ему списки полей, какие где выводятся - и этого будет достаточно.
Пример 2 (VCS):
В проектах с git'ом или любой другой VCS в параметры компонента обычно передаются не ID'шники (которые могут быть различными на dev, stage и prod-серверах), а что-то вроде getIblockIdByCode("news";). Скрыть такое от глаз неподготовленного человека тоже полезно.
Добавить в настройку activity Утверждение документа дополнительный параметр требовать комментарий при отказе:
Соответственно при установке опции поле комментария становится обязательным к заполнению в случае отказа.
Это позволит сэкономить время затрачиваемое на выяснение причин отказа по телефону или электронной почте.
Соответственно при установке опции поле комментария становится обязательным к заполнению в случае отказа.
Это позволит сэкономить время затрачиваемое на выяснение причин отказа по телефону или электронной почте.
© 2001-2022 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
