Первое и последнее сообщение.Ответ был дан в июне 2024
Евгений подсказал как сделать товар без вариаций, целых 2 варианта, и упомянул про баг с сохранением. Либо кусок моего комментария неверно цитирован, либо я не совсем понял в чем суть скриншота :)
Основная проблема работы с товарами с торговыми предложениями что не видно id товара в сделках, для его получения нужно вытащить торговое предложение.
Отойду от темы и вернусь в сторону гридов, интересно узнать отношение к hl блокам, как вы видите их использование, в прошлом году регулярно сталкивался с тем что свойства типа справочник в b24 не отображались в фильрах не выводились в слайдерах
Насколько мне известно в гриде товаров HL свойства должны отображаться корректно и в фильтре и в гриде.
Если это не так, то стоит обратиться в поддержку с указанием симптомов ;)
Делегирование вас к поддержке - это не формальная отписка, а действенный метод решения проблемы.
Так у нас выстроены процессы и чем больше обращения по одинаковой проблеме, тем выше приоритет у этой проблемы.
К сожалению я при всём желании не смогу переключиться на решение конкретно этой пробелмы, потому что написали комментарий на хабре))
Надеюсь вы понимаете.
Грид каталога всё ещё нельзя создать простой товар кроме как создать товар с торговыми предложениями и потом удалить торговые предложения без сохранения результата пойди объясни контент менеджеру что тут за магия и зачем это всё.
Насколько мне извествно все товары создаются с вариациями, в стандартных сценариях работы Битрикс24 проблем с этим не возникало.
Точно стоит преобразовывать файл в простой? :)
Что касается orm не сильно понятно как при создании аннотаций из 5 таблиц получаем файл на 19тыс строк при этом указав 1 модуль.
А других таблетов точно не завалялось в модуле?
Эта команда бегает по всему модулю и ищет там все таблеты и генерирует для них N классов-аннотаций.
Не знаю нужно ли это большому числу людей но в модулях хотелось бы видеть что меняется, changelog файл сделать или просто версию модуля писать, чтоб в гите видеть что вы меняете в модулях.
Изменения по модулям у нас приходят в месте самими версиями модуля при обновлении системы.
Если это не подходит, то просьба нам помочь и дать обратную связь (можно тут в комментах), что именно изложено не так и как это можно было бы исправить ;)
P.S. в этом году вышла новая документация к REST API (туц: https://apidocs.bitrix24.ru/ ). В целом есть в планах переработать подобным образом и также документацию для разработчиков, всё зависит от необходимости и запроса ;)
Вот это мне кажется определенного рода ошибка и с точки зрения процесса это должно быть прокси-методы в контроллеры модуля.
Отображение неизбежно скатиться к компоненту main.ui.grid, в каком бы контроллере не происходила обработка. Соответственно в предложенном варианте повсюду в контроллерах будут вызовы компонента main.ui.grid, для корректного формирования HTML и JS кода грида. Не сильно хорошо выглядит ;)
Т.е. компонент должен принять данные, дообработать кнопки "Для всех" и перенаправить на контроллер. В таком случае контроллер получиться переиспользуемым.
Именно это сейчас API грида и делает, подготовленные данные спускаются до конкретных экшонов грида/строк/панели и в них нужно только реализовать логику, без обвязки по обработке запроса.
Наверное вас смущает что эти экшоны находятся не в контроллерах, но это связанно с ограничениями, которые я описал выше. Ну и пожалуй "смущение" это единственный минус текущего подхода :)
Речь идет о том, чтобы перехватить данные между компонентом и гридом, чтобы подцепиться на коробке и изменить поведение.
Это вполне всё можно решить в текущей реализации добавив соответствующие DataProvider-ы в необходимых гридах (т.е. самостоятельно разработчиками).
Во встроенных гридах типа компании, сделки, товары и т.д. такие провайдеры не предусмотрены, в целом идея возможно имеет право существование, подумаем.
1.Судя по анализу кода template.php получается что все эти красивые классы служат исключительно для формирования правильных параметров в старый добрый "bitrix:main.ui.grid". Это так или все-таки некоторая "магия" внутри присутствует?
Верно, за отображение отвечает старый добрый "main.ui.grid", но внутри он также переработан для работы с объектами.
Дополнительно новое API служит для облегчения работы с обработкой запросов от грида и формированием структуры грида, а также переиспользования однотипного кода от грида к гриду с помощью выноса общей логики в провайдеры и ассемблеры.
Компонент лишь занимается отображением, всё остальное делает новое API.
2.Каким образом происходит связывание этого самого UserGrid, если согласно документации ни о каком gridId в листингах и речи нет?
Ид грида берётся из настроек, которые создаются в классе компонента: UserGridComponent::createGrid
Очень хочется прочесть про *Assembler классы их их влияние на отрисовку конкретных ячеек. Например когда мы манипулируем чистыми COLUMNT/ROWS мы имеем возможность создавать виртуальные строки комбинируя несколько столбцов - например можно взять "Дата договора" и "Номер договора" и комбинируя создать виртуальное поле. Интересно посмотреть как в данном случае будет выглядить Assembler такого поля?
Раскроем этот момент обязательно в документации, прямо сейчас нет под рукой подходящего примера ;)
Например вклиниться в стандартный список и обнулить значение ячейки в указанном гриде? Или добавить при помощи API доп. кнопок? Или по-прежнему js и распил?
Не совсем ясен пример. Рендерингом и логикой во фронтенд части в любом случае будет заниматься JS, как именно вы хотите его исключить из этой схемы? :)
Эх, видимо люди не то что "дальше контроллера перестали читать", но и самую первую строку тоже пропустили, раз такой холивар поднялся на тему "что такое юнит тест" :(
Для душнил продублирую тут основной посыл статьи, который в конце как раз отражён:
важнее писать тесты, чем заморачиваться над тем как они называются, и тем более заморачиваться над тем что должны быть только юнит-тесты.
Задача тестов, проверить реализованный функционал. Если я могу написать интеграционный/системный/приемочный, причем это будет быстрее чем написать юнит со всей кучей моков, то почему я должен писать юнит вместо подходящего теста? Поднять стенд с базой вроде ни у кого проблем не должно вызывать, либо по полноценному окружению гонять ночные тесты.
Дочитал только до контроллера, дальше желание пропало.
Опять тут у нас игра в слова началась. Unit - как бы подразумевает, что ты тестируешь некую конкретную функцианальностью в сферическом вакууме.
@pes_loxmaty а тест контроллера почему не удовлетворяет вашим требованиям? Тестируем конкретную функциональность, изолированно, отдельно от всего проекта aka в сферическом вакууме. Не вижу тут проблем. Или проблема в нейминге "контроллер" ?
Функциональные тесты, это подтверждение работы конкретной функциональности согласно ТЗ или беклогу.
Приемочное тестирование, это тестирование функциональность продукта методом «чёрного ящика» на соответствие заданным критериям.
@rsashka А функциональные тесты разве не могут тестировать функциональность на соответствие заданным критериям методом черного ящика? Из ваших определений следует что и функциональные и приемочные тесты могут внутри содержать абсолютно идентичные конструкции :)
Кстати вопрос, а чего такое тогда системные тесты? ;)
В том числе проверяется не сломалось ли что-то из "старого" функционала. Это у нас называется "acceptance tests". Но это у нас. В принципе это можно называть и как-то по другому.
@Kanutа разве проверка "что ничего не сломалось из старого" не называется регрессионными тестами? Что ж такое, опять какая-то путаница в этих определениях :o
На всякий случай оставлю тут эту картинку. Если кто-то захочет поискать другие подобные изображения, то уверяю они будут отличаться :)
Все стараются бороться с глобальными сущностями. Laravel: на тебе фасад, на тебе сигнлтон, на тебе глобальный объект :D
Ну а если по теме: чем этот подход лучше, обычного прокидывания сервиса через DI? Инджектим NotificationService в контроллере, инджектим в месте использования - профит. DI контейнер уже заботиться о том, чтобы инстанс был единственным экземпляром. Для такого способа как минимум будет меньше кода чем сейчас и нельзя будет вызывать NotificationService в любой точке кода (на всякий случай уточню что это херня полнейшая вызывать глобальные объекты где попало ;-) ).
Ну и по логики генерации заголовка: почему логика в NotificationResource? Это должно быть либо в фабрике DTO, либо внутри самого DTO (но это вариант опустим, т.к. в этом случае DTO перестанет быть DTO). А так получается что логика относящаяся к DTO утекла куда-то в другое место, которое никакое отношение не имеет к самому объекту.
Импакт от этого - переполнение базы данных путем создания различных юзеров.
А каким образом? Код одноразовый, т.е. когда мы его использовали, больше уже не получиться его использовать повторно.
После использования, если sid опять будет сгенерирован, то код проверки для него будет уже другой. И по факту написанный выше скрипт сработает только 1 раз.
Кажется тестировщики все же должны использовать реальные ящики ;)
Плюс визуал эта тулза точно корректно передает? В почте не просто HTML, там много своих ньюансов, и по хорошему надо смотреть популярные почтовые клиенты: Outlook, Gmail, Thunderbird и т.д.
Ну а если просто надо содержимое, то файлика в логе будет достаточно.
Это я к тому, что в зависимости от задачи тащить целый MailCatcher, может быть оверхедом. А в статье он как панацея обозначается)
Далее заходим в поисковик Яндекса и набираем ключевые слова: "английского репа MF DOOM
Просто случайно не заметили запятую в списке ключевых слов, да-да. Конечно же это человеческий запрос, все же мы гуглим именно так, а не по имени исполнителя. Нет-нет, конечно это все не ради красивой картинки с выдачей ТОП-1
Даже не знаю что хуже: что из пальца высасывают, либо что seo-шникой настолько тупой.
Да уже забудьте про эту хрень и не заучивайте её. SOLID проще и для понимания и для использования.
8 Какая система типов используется в PHP? Опишите плюсы и минусы.
Это вопрос из 90-х? Строгая типизация куда пропала?
19 Будут ли доступны частные методы trait в классе?
Ответ "Можно" :D
21 Расскажите об обработке ошибок и исключения (try catch, finaly и throw). Исключения необходимо для информативного оповещения об ошибке приложения.
Точно для этого? Я могу и 'trigger_error' заиспользовать, чтобы информативно что-то сообщить.
22 Что такое type hinting, как работает, зачем нужен?
После указанного ответа сразу же возникает вопрос "и что это дает?"
23 Что такое namespace-ы и зачем они нужны?
Удобное структурирование и группировка кода по контекстам (или иным причинам) вышли из чата.
29 Что такое замыкание в PHP? Приведите пример.
После указанного ответа сразу же возникает вопрос "зачем это use используется?"
31 Что такое позднее статическое связывание? Расскажите о поведении и применения static.
Ответ не понятнее вопроса :D
34 Расскажите о принципах SOLID. "Принцип единственной ответственности - Каждый объект ... а все его сервисы должны быть ..."
Это что за такие сервисы класса? У класс/объекта только свойства и методы.
34 Расскажите о принципах SOLID. "Это означает, что эти сущности могут менять свое поведение без изменения их исходного кода."
Это как? Я же должен написать код, чтобы что-то поменять в наследнике? Может тут все-таки речь про расширение поведения, с невозможность изменить изначальное?
34 Расскажите о принципах SOLID. "Принцип разделения интерфейса"
Это все хорошо (на самом деле нет), а интерфейсы то тут при чем? Если какой-то метод не используется клиентом, то этого метода не должно быть в интерфейсе!
-
Если честно я уже думал на этом закончить чтиво, но после увидел это:
И этот действительно богатый набор встроенного API по сути и выделяет его из массы других движков на сегодня и даёт вход в категорию CMF (content management framework), вроде как среднее звено между традиционным сайтовым движком и полноценным php web-фреймворком.
У WP или Joomla по вашему API меньше? Ссылку бы хотя бы на API оставили, чтобы понимать масштаб :) Забавно что вы мерите категорию фреймворк/не фреймворк размером API. Slim и емуподобные конечно грустят в сторонке от такого неравенства.
...стабильность движка с продуманной кодовой основой.
Что вкладывается в слово "стабильность"? Наличие мажорной цифры в номере версии? Малое число issue, а также отсутствие тестов (по крайней мере в репе) говорит скорее об обратном и том что могут быть скрытые дефекты.
Стабильно плохо - это все равно плохо :)
Касательно уникальности & гибкости дизайна - тут опять свобода (а это часто предполагает ответственность), задействуй css библиотечки на вкус и на тебе авторский сайт(!)
А у кого нет?
какие поля не создавай в админке, сообразно таблицы и типы формируются в базе, и далее манипулируются через ту же админ-панель.
А у кого нет?
Безопасность, производительность, ... - это всё про PW.
Плюс в комментариях выше правильно написали про использованную память. Я думаю стоит также добавить в статью сколько памяти сожралось при том или ином варианте.
Ну и еще как вариант можно запросы делать пачками по 1К, 10К, 100К элементов, а не собирать один большой монструозный запрос
В данный момент из коробки это сделать не получится, нужно использовать столбец с типом
customи формировать HTML для отображения селектора.Типа такого:
Евгений подсказал как сделать товар без вариаций, целых 2 варианта, и упомянул про баг с сохранением. Либо кусок моего комментария неверно цитирован, либо я не совсем понял в чем суть скриншота :)
Ну это же не сама цель, зачем-то ид этот нужен :)
Выходом из ситуации для решения конкретной задачи может быть уже вышеупомянутый рест, когда получая ид товара, можно получить список предложений с помощью фильтра по свойству: https://apidocs.bitrix24.ru/api-reference/catalog/product/offer/catalog-product-offer-list.html
Вот репа по прототипу https://github.com/bitrix24/framework3-prototype
Актуальное состояние проекта зафиксировано в репозитории. Как-то так
Насколько мне известно в гриде товаров HL свойства должны отображаться корректно и в фильтре и в гриде.
Если это не так, то стоит обратиться в поддержку с указанием симптомов ;)
Делегирование вас к поддержке - это не формальная отписка, а действенный метод решения проблемы.
Так у нас выстроены процессы и чем больше обращения по одинаковой проблеме, тем выше приоритет у этой проблемы.
К сожалению я при всём желании не смогу переключиться на решение конкретно этой пробелмы, потому что написали комментарий на хабре))
Надеюсь вы понимаете.
Насколько мне извествно все товары создаются с вариациями, в стандартных сценариях работы Битрикс24 проблем с этим не возникало.
Точно стоит преобразовывать файл в простой? :)
А других таблетов точно не завалялось в модуле?
Эта команда бегает по всему модулю и ищет там все таблеты и генерирует для них N классов-аннотаций.
Изменения по модулям у нас приходят в месте самими версиями модуля при обновлении системы.
Отдельно по каждым подулям changelog можно посмотреть туц: https://dev.1c-bitrix.ru/docs/versions.php
В данный момент у нас уже есть хорошая и достаточно полная документация по работе с 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/ ). В целом есть в планах переработать подобным образом и также документацию для разработчиков, всё зависит от необходимости и запроса ;)
Отображение неизбежно скатиться к компоненту main.ui.grid, в каком бы контроллере не происходила обработка. Соответственно в предложенном варианте повсюду в контроллерах будут вызовы компонента main.ui.grid, для корректного формирования HTML и JS кода грида. Не сильно хорошо выглядит ;)
Именно это сейчас API грида и делает, подготовленные данные спускаются до конкретных экшонов грида/строк/панели и в них нужно только реализовать логику, без обвязки по обработке запроса.
Наверное вас смущает что эти экшоны находятся не в контроллерах, но это связанно с ограничениями, которые я описал выше. Ну и пожалуй "смущение" это единственный минус текущего подхода :)
Это вполне всё можно решить в текущей реализации добавив соответствующие DataProvider-ы в необходимых гридах (т.е. самостоятельно разработчиками).
Во встроенных гридах типа компании, сделки, товары и т.д. такие провайдеры не предусмотрены, в целом идея возможно имеет право существование, подумаем.
Верно, за отображение отвечает старый добрый "main.ui.grid", но внутри он также переработан для работы с объектами.
Дополнительно новое API служит для облегчения работы с обработкой запросов от грида и формированием структуры грида, а также переиспользования однотипного кода от грида к гриду с помощью выноса общей логики в провайдеры и ассемблеры.
Компонент лишь занимается отображением, всё остальное делает новое API.
Ид грида берётся из настроек, которые создаются в классе компонента:
UserGridComponent::createGridРаскроем этот момент обязательно в документации, прямо сейчас нет под рукой подходящего примера ;)
Не совсем ясен пример.
Рендерингом и логикой во фронтенд части в любом случае будет заниматься JS, как именно вы хотите его исключить из этой схемы? :)
Репозиторий с примерами из статьи: https://github.com/irpsv/bitrix-grid-example
;-)
Как обновление будет доступно я дополнительно отпишусь в комментах тут.
В описании самого обновления модуля также будет указана информация.
Действительно, упустил этот момент. Чуть позже создам репозиторий и там разложу файлики, чтобы было наглядно всё видно!
Компонент и шаблон компонента располагаются согласно иерархии битрикс компонентов: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=2818&LESSON_PATH=3913.2704.2881.2818
А классы уже располагаются в модуле.
Эх, видимо люди не то что "дальше контроллера перестали читать", но и самую первую строку тоже пропустили, раз такой холивар поднялся на тему "что такое юнит тест" :(
Для душнил продублирую тут основной посыл статьи, который в конце как раз отражён:
Задача тестов, проверить реализованный функционал. Если я могу написать интеграционный/системный/приемочный, причем это будет быстрее чем написать юнит со всей кучей моков, то почему я должен писать юнит вместо подходящего теста? Поднять стенд с базой вроде ни у кого проблем не должно вызывать, либо по полноценному окружению гонять ночные тесты.
@pes_loxmaty а тест контроллера почему не удовлетворяет вашим требованиям? Тестируем конкретную функциональность, изолированно, отдельно от всего проекта aka в сферическом вакууме. Не вижу тут проблем. Или проблема в нейминге "контроллер" ?
@rsashka А функциональные тесты разве не могут тестировать функциональность на соответствие заданным критериям методом черного ящика? Из ваших определений следует что и функциональные и приемочные тесты могут внутри содержать абсолютно идентичные конструкции :)
Кстати вопрос, а чего такое тогда системные тесты? ;)
@Kanutа разве проверка "что ничего не сломалось из старого" не называется регрессионными тестами? Что ж такое, опять какая-то путаница в этих определениях :o
На всякий случай оставлю тут эту картинку. Если кто-то захочет поискать другие подобные изображения, то уверяю они будут отличаться :)
Все стараются бороться с глобальными сущностями. Laravel: на тебе фасад, на тебе сигнлтон, на тебе глобальный объект :D
Ну а если по теме: чем этот подход лучше, обычного прокидывания сервиса через DI? Инджектим NotificationService в контроллере, инджектим в месте использования - профит. DI контейнер уже заботиться о том, чтобы инстанс был единственным экземпляром. Для такого способа как минимум будет меньше кода чем сейчас и нельзя будет вызывать NotificationService в любой точке кода (на всякий случай уточню что это херня полнейшая вызывать глобальные объекты где попало ;-) ).
Ну и по логики генерации заголовка: почему логика в NotificationResource? Это должно быть либо в фабрике DTO, либо внутри самого DTO (но это вариант опустим, т.к. в этом случае DTO перестанет быть DTO). А так получается что логика относящаяся к DTO утекла куда-то в другое место, которое никакое отношение не имеет к самому объекту.
А каким образом? Код одноразовый, т.е. когда мы его использовали, больше уже не получиться его использовать повторно.
После использования, если sid опять будет сгенерирован, то код проверки для него будет уже другой. И по факту написанный выше скрипт сработает только 1 раз.
Что я упускаю?
Кажется тестировщики все же должны использовать реальные ящики ;)
Плюс визуал эта тулза точно корректно передает? В почте не просто HTML, там много своих ньюансов, и по хорошему надо смотреть популярные почтовые клиенты: Outlook, Gmail, Thunderbird и т.д.
Ну а если просто надо содержимое, то файлика в логе будет достаточно.
Это я к тому, что в зависимости от задачи тащить целый MailCatcher, может быть оверхедом. А в статье он как панацея обозначается)
Решение реализовать свой
custom_mailи писать почту в лог файлик, почему не подошло?https://dev.1c-bitrix.ru/community/webdev/user/16002/blog/1073/
Просто случайно не заметили запятую в списке ключевых слов, да-да. Конечно же это человеческий запрос, все же мы гуглим именно так, а не по имени исполнителя. Нет-нет, конечно это все не ради красивой картинки с выдачей ТОП-1
Даже не знаю что хуже: что из пальца высасывают, либо что seo-шникой настолько тупой.
А когда это массив и объект скалярами стали? https://www.php.net/manual/ru/function.is-scalar
Да уже забудьте про эту хрень и не заучивайте её.
SOLID проще и для понимания и для использования.
Это вопрос из 90-х? Строгая типизация куда пропала?
Ответ "Можно" :D
Точно для этого? Я могу и 'trigger_error' заиспользовать, чтобы информативно что-то сообщить.
После указанного ответа сразу же возникает вопрос "и что это дает?"
Удобное структурирование и группировка кода по контекстам (или иным причинам) вышли из чата.
После указанного ответа сразу же возникает вопрос "зачем это
useиспользуется?"Ответ не понятнее вопроса :D
Это что за такие сервисы класса? У класс/объекта только свойства и методы.
Это как? Я же должен написать код, чтобы что-то поменять в наследнике?
Может тут все-таки речь про расширение поведения, с невозможность изменить изначальное?
Это все хорошо (на самом деле нет), а интерфейсы то тут при чем?
Если какой-то метод не используется клиентом, то этого метода не должно быть в интерфейсе!
-
Если честно я уже думал на этом закончить чтиво, но после увидел это:
ЗАЧЕМ? Зачем про это спрашивать?
У WP или Joomla по вашему API меньше? Ссылку бы хотя бы на API оставили, чтобы понимать масштаб :)
Забавно что вы мерите категорию фреймворк/не фреймворк размером API. Slim и емуподобные конечно грустят в сторонке от такого неравенства.
Что вкладывается в слово "стабильность"? Наличие мажорной цифры в номере версии? Малое число issue, а также отсутствие тестов (по крайней мере в репе) говорит скорее об обратном и том что могут быть скрытые дефекты.
Стабильно плохо - это все равно плохо :)
А у кого нет?
А у кого нет?
Пруфы?
Статья про транзакции, а не про вложенность. Вложенность работает так под капотом:
Статья хорошая, но в целом про работу с сохранением из коллекции в доке есть: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=11749&LESSON_PATH=3913.3516.5748.11743.11749
Плюс в комментариях выше правильно написали про использованную память. Я думаю стоит также добавить в статью сколько памяти сожралось при том или ином варианте.
Ну и еще как вариант можно запросы делать пачками по 1К, 10К, 100К элементов, а не собирать один большой монструозный запрос