Information
- Rating
- 8,873-rd
- Location
- Курган, Курганская обл., Россия
- Works in
- Date of birth
- Registered
- Activity
Specialization
Fullstack Developer, Software Architect
Senior
PHP
Docker
Database
OOP
Algorithms and data structures
Object-oriented design
Database design
Software development
Designing application architecture
Крутая статья, спасибо вам!
Пример достаточно простой, но как быть если проект большой? :)
Т.е. в текущем примере у вас модуль
Shop
, но в реальных проектах модулей как минимум 10, а если мы говорим еще и про контексты внутри домена, то иерархия достаточно сложная. Как это всё должно выглядеть?Подкол был в том, что у вас возникли вопросы к Битрикс, и не возникли к Yii и Laravel, которые тоже свои валидаторы сделали, а не заиспользовали Symfony ;)
А почему вы так решили? Валидацией занимаются валидаторы, атрибуты привязываются к полю и поставляют валидаторы, которыми это поле нужно проверить. В самой статье есть отдельный абзац и пример про использование валидаторов без атрибутов.
Как мне кажется, нигде кроме symfony вы и не найдёте вынос правил валидации в yaml файл :D
Нужно ли валидацию насколько далеко уносить от кода, который её использует? Очень сомнительно.
Если речь про атрибут свойства - то да, валидироваться будет только значение одного свойства.
Если сделать атрибут класса - то он принимает весь объект и может формировать любые правила и условия. В статье проверка нескольких полей отражена в примере
AtLeastOnePropertyNotEmpty
Напишите пример как это должно работать по вашему мнению, желательно на примере валидаторов симфони, раз уж вы начали сравнивать с ним ;)
А в чем проблема? Создаете атрибут
DoesNotContainSwearWords
, который принимает все настройки и поставляет нужный валидатор, создаете собственно этот валидаторDoesNotContainSwearWordsValidator
, который реализует необходимую вам логику.А прочей это какой? И насколько это надо для операции валидации конкретного поля?
Опять же если сопроводите примерами из symfony, будет невероятно великолепно ;)
А вы в целом работали с Битрикс? Знаете что он не через composer устанавливается? :)
Потому что Битрикс это не библиотечка, которая собирается из packagist-a . Внедрять сторонний компонент, с кучей сторонних зависимостей, в коммерческий проект, который затем неизбежно будет зависеть от этого стороннего решения - крайне плохая мысль. Тем более если речь про конкретный функционал.
Адаптация и интеграция того самого великолепного решения, которое лучше в тыщу раз, под используемые в Битрикс классы и сущности также не задача из разряда "просто сделай composer require".
Ну и вам уже надо определиться с вашим отношением к валидации в Битрикс: это всё-таки "копи-паста" или же это "худшая реализация" ;)
Я тоже с точки зрения здравого смысла не понимаю зачем нужны еще какие-то решения и фреймворки, если есть symfony ;)
А чем Битрикс хуже чем Yii или Laravel? Тоже хочется велосипед :)
В данный момент из коробки это сделать не получится, нужно использовать столбец с типом
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
Это что за такие сервисы класса? У класс/объекта только свойства и методы.
Это как? Я же должен написать код, чтобы что-то поменять в наследнике?
Может тут все-таки речь про расширение поведения, с невозможность изменить изначальное?
Это все хорошо (на самом деле нет), а интерфейсы то тут при чем?
Если какой-то метод не используется клиентом, то этого метода не должно быть в интерфейсе!
-
Если честно я уже думал на этом закончить чтиво, но после увидел это:
ЗАЧЕМ? Зачем про это спрашивать?