Идеи пользователя
Хотелось, чтобы была возможность изменять минимальную цену товара в зависимости от различных данных. Для этого можно добавить событие, которое будет вызываться до/после установки MIN_PRICE товара.
Добавить возможность передать в функцию BX.showWait свой объект стилей или как-то изменять стандартный объект стилей прелоадера, чтобы использовать стилизованные прелоадеры, возможно разные на одном сайте, в том числе вызываемые стандартными компонентами.
Google PageSpped ругается на все сайты на Битриксе в контексте того, что в шапке сайта подключается огромная объединённая и сжатая CSS. Согласно рекомендациям в шапке сайта нужно подключать только те CSS, которые нужны на первом экране. Но в Битриксе же все все css всех шаблонов компонентов подключаются исключительно в шапке. Нужно дать возможность в шаблоне компонента голосовать за место расположения CSS - Header/Footer. По аналогии с голосованием за композит. На выходе получим то, что требует Google - в шапке будут подключаться только те CSS, которые нужны для первого экрана, остальные соответственно будут подключаться в подвале сайта.
Очень нужна возможность подписаться на события вызова шаблонов компонентов. Реальный кейс - компиляция less файлов в шаблоне компонента, а также автоматическое создание script.min.js и опционально обфускация JS.
Сейчас приходится в каждом шаблоне в component_epilog протаскивать методы компиляции/минимизации. Не удобно.
Сейчас приходится в каждом шаблоне в component_epilog протаскивать методы компиляции/минимизации. Не удобно.
В версии инфоблоков 16.5.4 вышла прекрасная функциональность для работы с разделами на новом ядре D7.
Правда документации пока нет (но ничего страшного) и можно было бы существенно увеличить возможности новой реализации:
1) Метод compileEntityByIblock мог бы возвращать не полное название класса, а объект этого класса. При этом его работа была бы эффективнее. Сравните 2 подхода:
Против
Мне кажется решение под номером 2 выглядит практичнее.
2) Предлагаю расширить модель SectionTable (или ее производные типа Section1Table) на runtime параметр: ELEMENT_COUNT - который бы доставал активные элементы, привязанные к соответствующему разделу.
Кейс: нужно отобразить только те разделы, где есть активные элементы.
Решение предлагаемое из коробки - составление своего runtime-поля для каждого getList/getRow (где оно требуется).
Если добавить штатное решение как SELECT поле и просто передавать его в массиве полей или соответственно по условию, то код будет выглядеть элегантнее и проще, а другие подобные поля, можно будет посмотреть и сделать по аналогии.
Правда документации пока нет (но ничего страшного) и можно было бы существенно увеличить возможности новой реализации:
1) Метод compileEntityByIblock мог бы возвращать не полное название класса, а объект этого класса. При этом его работа была бы эффективнее. Сравните 2 подхода:
use \Bitrix\Main\Loader;
use \Bitrix\Iblock\Model\Section as SectionFactory;
Loader::IncludeModule('iblock');
$sSection = SectionFactory::compileEntityByIblock(1);
$oEntity = new $sSection;
var_dump($oEntity->getMap()); |
Против
use \Bitrix\Main\Loader;
use \Bitrix\Iblock\Model\Section as SectionFactory;
Loader::IncludeModule('iblock');
$oEntity = SectionFactory::compileEntityByIblock(1);
var_dump($oEntity->getMap()); |
Мне кажется решение под номером 2 выглядит практичнее.
2) Предлагаю расширить модель SectionTable (или ее производные типа Section1Table) на runtime параметр: ELEMENT_COUNT - который бы доставал активные элементы, привязанные к соответствующему разделу.
Кейс: нужно отобразить только те разделы, где есть активные элементы.
Решение предлагаемое из коробки - составление своего runtime-поля для каждого getList/getRow (где оно требуется).
Если добавить штатное решение как SELECT поле и просто передавать его в массиве полей или соответственно по условию, то код будет выглядеть элегантнее и проще, а другие подобные поля, можно будет посмотреть и сделать по аналогии.
20 символов, для имени сущности очень мало.
Туда даже не поместится название модуля.
Сделайте хотя бы 30, а лучше 50, чтобы я мог придумывать уникальные имена объектам и не нарушать правила маркетплейса.
Туда даже не поместится название модуля.
Сделайте хотя бы 30, а лучше 50, чтобы я мог придумывать уникальные имена объектам и не нарушать правила маркетплейса.
Было бы отлично "открыть" процесс разработки Bitrix Framework для всеобщего обозрения, например на GitHub, и таким образом получить возможность другим разработчикам тоже контрибутить продукт.
Приведу пример:
Человек нашел как сделать улучшение в продукте и знает как конкретно это сделать. Скорее всего, ему совсем не составить труда сделать pull-реквест с этим изменением, а core-разработчикам останется только сделать ревью, провести тесты и смержить изменения, если все устраивает. Не секрет, что так живут все популярные PHP-фреймворки.
Но с текущим процессом, мы можем лишь создать идею в этом портале и ждать много времени пока это воплотят в жизнь. Тем более, вряд ли такие идеи быстро дойдут до отдела разработки.
Компания 1С-Битрикс заявляет, что система имеет открытый исходный код (или частично открытый), кто разбирается в теме, подскажите, на сколько реально это сделать.
Спасибо
Приведу пример:
Человек нашел как сделать улучшение в продукте и знает как конкретно это сделать. Скорее всего, ему совсем не составить труда сделать pull-реквест с этим изменением, а core-разработчикам останется только сделать ревью, провести тесты и смержить изменения, если все устраивает. Не секрет, что так живут все популярные PHP-фреймворки.
Но с текущим процессом, мы можем лишь создать идею в этом портале и ждать много времени пока это воплотят в жизнь. Тем более, вряд ли такие идеи быстро дойдут до отдела разработки.
Компания 1С-Битрикс заявляет, что система имеет открытый исходный код (или частично открытый), кто разбирается в теме, подскажите, на сколько реально это сделать.
Спасибо
Добрый день.
Возник момент с кастомным кешированием в своем компоненте.
Согласно этому курсу (), подключение шаблона можно размещать как в кешируемой области, так и вне её.
При подключении шаблона в кешируемой области собственного компонента со сложным кешированием шаблон не отрабатывает вообще - сразу выводится 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, нужно подключение шаблона обязательно выводить из кешируемой области.
Прошу дать возможность разработчику самостоятельно подключать эпилог компонента в своем компоненте.
Хорошо было бы иметь возможность реализовывать кастомные скидки. По аналогии с кастомной автоматизированной службой доставки.
Приведу пример: у заказчика есть скидки по местоположению. Допустим в Московской области скидки нет, в Ленинградской есть.
В своё время, конечно, мы использовали CALLBACK_FUNC (кстати, уже устаревший со временим механизм). Идут года и CALLBACK_FUNC вымрет окончательно и придется переделывать эту логику (которая уже реализована достаточно извращенным способом на инфоблоках).
Если б было что-то вроде хендлера, который бы при просчете скидки, которая сейчас реализуется в функции CSaleDiscount:: DoProcessOrder, дергал бы кастомные службы скидок, было бы гораздо удобнее.
Приведу пример: у заказчика есть скидки по местоположению. Допустим в Московской области скидки нет, в Ленинградской есть.
В своё время, конечно, мы использовали CALLBACK_FUNC (кстати, уже устаревший со временим механизм). Идут года и CALLBACK_FUNC вымрет окончательно и придется переделывать эту логику (которая уже реализована достаточно извращенным способом на инфоблоках).
Если б было что-то вроде хендлера, который бы при просчете скидки, которая сейчас реализуется в функции CSaleDiscount:: DoProcessOrder, дергал бы кастомные службы скидок, было бы гораздо удобнее.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
