Комментарии 21
Для тех, кто побежал искать Bitrix\Main\Grid\TabletGrid важное в конце:
Описанный функционал выйдет совсем скоро в свежем апдейте модуля main, не забудьте обновиться ;-)
Этого ещё нет. Автор не сообщает с какой версии ядра это появится.
Поэтому ждём) Но статью в закладки добавляем)))
Добрый вечер. Выглядит действительно проще чем вариант где надо было добавлять кусочки отдельно.
А можно добавить какой-нибудь скрин со структурой файлов? А то сразу не оч понятно какой уровень вложенности разных файлов.
Например компонент, класс, и шаблон на одном уровене в папке или как-то по папкам разделены?
А можно добавить какой-нибудь скрин со структурой файлов? А то сразу не оч понятно какой уровень вложенности разных файлов.
Действительно, упустил этот момент. Чуть позже создам репозиторий и там разложу файлики, чтобы было наглядно всё видно!
Например компонент, класс, и шаблон на одном уровене в папке или как-то по папкам разделены?
Компонент и шаблон компонента располагаются согласно иерархии битрикс компонентов: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=2818&LESSON_PATH=3913.2704.2881.2818
А классы уже располагаются в модуле.
Репозиторий с примерами из статьи: https://github.com/irpsv/bitrix-grid-example
;-)
Очень интересная статья и особенно радует что статей от разработчиков самого Битрикс24 становиться все больше, а движение приобретает правильный вектор. Хочется надеяться что документация по механикам так же будет написана, чтобы эта статья не стала единственным источником информации.
Однако в статье я заметил ряд очень необычных моментов на которые хотелось бы получить комментарии:
Судя по анализу кода template.php получается что все эти красивые классы служат исключительно для формирования правильных параметров в старый добрый "bitrix:main.ui.grid". Это так или все-таки некоторая "магия" внутри присутствует?
В первом листинге кода мы создаем некоторый класс "UserGrid" наследника "TabletGrid", который якобы должен реализовывать объект грида, однако уже в третьем листинге кода мы видим некоторый "ComponentParams::get" который магическим образом по gridId достает параметры. Каким образом происходит связывание этого самого UserGrid, если согласно документации ни о каком gridId в листингах и речи нет?
Очень хочется прочесть про *Assembler классы их их влияние на отрисовку конкретных ячеек. Например когда мы манипулируем чистыми COLUMNT/ROWS мы имеем возможность создавать виртуальные строки комбинируя несколько столбцов - например можно взять "Дата договора" и "Номер договора" и комбинируя создать виртуальное поле. Интересно посмотреть как в данном случае будет выглядить Assembler такого поля?
Получило ли "новое api" гридов что-то действительно новое в части кастомизации? Будут ли возможности кастомизации существующих гридов построенных на базе этой технологии? Например вклиниться в стандартный список и обнулить значение ячейки в указанном гриде? Или добавить при помощи API доп. кнопок? Или по-прежнему js и распил?
1.Судя по анализу кода template.php получается что все эти красивые классы служат исключительно для формирования правильных параметров в старый добрый "bitrix:main.ui.grid". Это так или все-таки некоторая "магия" внутри присутствует?
Верно, за отображение отвечает старый добрый "main.ui.grid", но внутри он также переработан для работы с объектами.
Дополнительно новое API служит для облегчения работы с обработкой запросов от грида и формированием структуры грида, а также переиспользования однотипного кода от грида к гриду с помощью выноса общей логики в провайдеры и ассемблеры.
Компонент лишь занимается отображением, всё остальное делает новое API.
2.Каким образом происходит связывание этого самого UserGrid, если согласно документации ни о каком gridId в листингах и речи нет?
Ид грида берётся из настроек, которые создаются в классе компонента: UserGridComponent::createGrid
Очень хочется прочесть про *Assembler классы их их влияние на отрисовку конкретных ячеек. Например когда мы манипулируем чистыми COLUMNT/ROWS мы имеем возможность создавать виртуальные строки комбинируя несколько столбцов - например можно взять "Дата договора" и "Номер договора" и комбинируя создать виртуальное поле. Интересно посмотреть как в данном случае будет выглядить Assembler такого поля?
Раскроем этот момент обязательно в документации, прямо сейчас нет под рукой подходящего примера ;)
Например вклиниться в стандартный список и обнулить значение ячейки в указанном гриде? Или добавить при помощи API доп. кнопок? Или по-прежнему js и распил?
Не совсем ясен пример.
Рендерингом и логикой во фронтенд части в любом случае будет заниматься JS, как именно вы хотите его исключить из этой схемы? :)
Верно, за отображение отвечает старый добрый "main.ui.grid", но внутри он также переработан для работы с объектами.
Вот об этом то и вопрос - судя по представленному API, это исключительно внешняя обертка уже известных механик, а смысла обязывать параметры сильно не вижу.
Дополнительно новое API служит для облегчения работы с обработкой запросов от грида и формированием структуры грида, а также переиспользования однотипного кода от грида к гриду с помощью выноса общей логики в провайдеры и ассемблеры.
Вот это мне кажется определенного рода ошибка и с точки зрения процесса это должно быть прокси-методы в контроллеры модуля.
Т.е. компонент должен принять данные, дообработать кнопки "Для всех" и перенаправить на контроллер. В таком случае контроллер получиться переиспользуемым.
Сейчас то что есть - это некоторый альтернативный контроллер компонента, а зачем еще один action, когда можно было использовать его?
Не совсем ясен пример.
Рендерингом и логикой во фронтенд части в любом случае будет заниматься JS, как именно вы хотите его исключить из этой схемы? :)
Речь идет о том, чтобы перехватить данные между компонентом и гридом, чтобы подцепиться на коробке и изменить поведение.
Потенциально это очень мощная штука, с которой некоторые бизнес-задачи будут намного проще.
Например:
Убрать какие-то столбцы у сотрудника. Например запретить "курьерам" видеть номер телефона или поля типа "Серия и номер паспорта".
Добавить свои столбцы без модификации компонентов
Дополнить действия над строкой.
Это навскидку задачи, которые могут быть легко решены, если появится точка между кодом и компонентом.
Вот это мне кажется определенного рода ошибка и с точки зрения процесса это должно быть прокси-методы в контроллеры модуля.
Отображение неизбежно скатиться к компоненту main.ui.grid, в каком бы контроллере не происходила обработка. Соответственно в предложенном варианте повсюду в контроллерах будут вызовы компонента main.ui.grid, для корректного формирования HTML и JS кода грида. Не сильно хорошо выглядит ;)
Т.е. компонент должен принять данные, дообработать кнопки "Для всех" и перенаправить на контроллер. В таком случае контроллер получиться переиспользуемым.
Именно это сейчас API грида и делает, подготовленные данные спускаются до конкретных экшонов грида/строк/панели и в них нужно только реализовать логику, без обвязки по обработке запроса.
Наверное вас смущает что эти экшоны находятся не в контроллерах, но это связанно с ограничениями, которые я описал выше. Ну и пожалуй "смущение" это единственный минус текущего подхода :)
Речь идет о том, чтобы перехватить данные между компонентом и гридом, чтобы подцепиться на коробке и изменить поведение.
Это вполне всё можно решить в текущей реализации добавив соответствующие DataProvider-ы в необходимых гридах (т.е. самостоятельно разработчиками).
Во встроенных гридах типа компании, сделки, товары и т.д. такие провайдеры не предусмотрены, в целом идея возможно имеет право существование, подумаем.
UPD: Не туда ответил. Удаляю
Можно еще ORM в порядок привести и сделать нормальные гайды как с ней работать и в целом определится как у Вас устроена архитектура.
В данный момент у нас уже есть хорошая и достаточно полная документация по работе с ORM: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&CHAPTER_ID=05748&LESSON_PATH=3913.3516.5748
Конкретно по инфоблокам также есть раздел (про концепцию с архитектурой тоже): https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&CHAPTER_ID=012864&LESSON_PATH=3913.3516.5748.12864
Если это не подходит, то просьба нам помочь и дать обратную связь (можно тут в комментах), что именно изложено не так и как это можно было бы исправить ;)
P.S. в этом году вышла новая документация к REST API (туц: https://apidocs.bitrix24.ru/ ). В целом есть в планах переработать подобным образом и также документацию для разработчиков, всё зависит от необходимости и запроса ;)
Отойду от темы и вернусь в сторону гридов, интересно узнать отношение к hl блокам, как вы видите их использование, в прошлом году регулярно сталкивался с тем что свойства типа справочник в b24 не отображались в фильрах не выводились в слайдерах, где-то их до сих пор нельзя создать, как пример в /crm/configs/productprops/ не доступно создание свойств типа справочник, а из детальной страницы товара их можно создать, но нельзя указать код что мешает при обмене с внешними системами, при этом если заходить через каталог и в настройках найти свойства то там они есть и можно задать даже код. Получаем 3 разных поведения и 3 разных места где можно создавать свойства.
Грид каталога всё ещё нельзя создать простой товар кроме как создать товар с торговыми предложениями и потом удалить торговые предложения без сохранения результата пойди объясни контент менеджеру что тут за магия и зачем это всё.
Что касается orm не сильно понятно как при создании аннотаций из 5 таблиц получаем файл на 19тыс строк при этом указав 1 модуль.
Из последнего:
Берём доку https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=20656&LESSON_PATH=3913.3516.5748.5063.20656 тут нам говорят что setDefaultScope
"Метод setDefaultScope будет выполняться при каждом запросе, пропуская через себя объект запроса. В нем можно задавать не только фильтр, но и любые другие параметры запроса."
Видим что select перебирается до вызова метода, как итог использовать addSelect не выходит в setDefaultScope.
Работаем с инфоблокаи, отнаследовались делаем выборку через CarTable::query() получаем все элементы всех инфоблоков, поэтому пользуем setDefaultScope и задаём фильтр по IBLOCK_ID, кажется так не должно быть.
Так это про чтение, если появляются задачи где интеграция с внешней системой и там нужно писать, сдуваем пыль и берём старое ядро.
Опять же смотрим доку видим и это уже давно так
Может я чего не понимаю, но кажется у компании нет глубокого видения как работать с продуктом, либо курсов нет.
Не знаю нужно ли это большому числу людей но в модулях хотелось бы видеть что меняется, changelog файл сделать или просто версию модуля писать, чтоб в гите видеть что вы меняете в модулях.
То что для rest библиотека в гите лежит выглядит как победа, я порадовался)
Отойду от темы и вернусь в сторону гридов, интересно узнать отношение к hl блокам, как вы видите их использование, в прошлом году регулярно сталкивался с тем что свойства типа справочник в b24 не отображались в фильрах не выводились в слайдерах
Насколько мне известно в гриде товаров HL свойства должны отображаться корректно и в фильтре и в гриде.
Если это не так, то стоит обратиться в поддержку с указанием симптомов ;)
Делегирование вас к поддержке - это не формальная отписка, а действенный метод решения проблемы.
Так у нас выстроены процессы и чем больше обращения по одинаковой проблеме, тем выше приоритет у этой проблемы.
К сожалению я при всём желании не смогу переключиться на решение конкретно этой пробелмы, потому что написали комментарий на хабре))
Надеюсь вы понимаете.
Грид каталога всё ещё нельзя создать простой товар кроме как создать товар с торговыми предложениями и потом удалить торговые предложения без сохранения результата пойди объясни контент менеджеру что тут за магия и зачем это всё.
Насколько мне извествно все товары создаются с вариациями, в стандартных сценариях работы Битрикс24 проблем с этим не возникало.
Точно стоит преобразовывать файл в простой? :)
Что касается orm не сильно понятно как при создании аннотаций из 5 таблиц получаем файл на 19тыс строк при этом указав 1 модуль.
А других таблетов точно не завалялось в модуле?
Эта команда бегает по всему модулю и ищет там все таблеты и генерирует для них N классов-аннотаций.
Не знаю нужно ли это большому числу людей но в модулях хотелось бы видеть что меняется, changelog файл сделать или просто версию модуля писать, чтоб в гите видеть что вы меняете в модулях.
Изменения по модулям у нас приходят в месте самими версиями модуля при обновлении системы.
Отдельно по каждым подулям changelog можно посмотреть туц: https://dev.1c-bitrix.ru/docs/versions.php
Насколько мне извествно все товары создаются с вариациями, в стандартных сценариях работы Битрикс24 проблем с этим не возникало.
Первое и последнее сообщение.
Ответ был дан в июне 2024
Насколько мне извествно все товары создаются с вариациями, в стандартных сценариях работы Битрикс24 проблем с этим не возникало.
Первое и последнее сообщение.
Ответ был дан в июне 2024
Основная проблема работы с товарами с торговыми предложениями что не видно id товара в сделках, для его получения нужно вытащить торговое предложение.
Первое и последнее сообщение.Ответ был дан в июне 2024
Евгений подсказал как сделать товар без вариаций, целых 2 варианта, и упомянул про баг с сохранением. Либо кусок моего комментария неверно цитирован, либо я не совсем понял в чем суть скриншота :)
Основная проблема работы с товарами с торговыми предложениями что не видно id товара в сделках, для его получения нужно вытащить торговое предложение.
Ну это же не сама цель, зачем-то ид этот нужен :)
Выходом из ситуации для решения конкретной задачи может быть уже вышеупомянутый рест, когда получая ид товара, можно получить список предложений с помощью фильтра по свойству: https://apidocs.bitrix24.ru/api-reference/catalog/product/offer/catalog-product-offer-list.html
Можете написать что стало с идеей "Новый Bitrix Framework" 3 года как прошло уже, вроде даже был репозиторий на github, но не смог его найти
https://www.youtube.com/watch?v=SU_vUZL-190
Вот репа по прототипу https://github.com/bitrix24/framework3-prototype
Актуальное состояние проекта зафиксировано в репозитории. Как-то так
Коллеги, есть необходимость в реализации в гридах инлайн редактирование полей, с типами Привязка к сотруднику и Привязка к CRM.
В данный момент из коробки это сделать не получится, нужно использовать столбец с типом custom и формировать HTML для отображения селектора.
Типа такого:
<?php
// провайдер столбцов
final class ExampleProvider extends \Bitrix\Main\Grid\Column\DataProvider
{
public function prepareColumns(): array
{
return [
'crm_entity' => (new \Bitrix\Main\Grid\Column\Column('company'))
->setType(\Bitrix\Main\Grid\Column\Type::CUSTOM)
,
];
}
}
// ассемблер нужного поля
final class CrmEntityFieldAssembler extends \Bitrix\Main\Grid\Row\FieldAssembler
{
protected function prepareRow(array $row): array
{
$row = parent::prepareRow($row);
foreach ($this->getColumnIds() as $columnId)
{
$row['data']['~' . $columnId] = [
'HTML' => '...',
];
}
return $row;
}
}
Гриды в Битрикс24: теперь не нужно искать сторонние решения