За освещение проблемы однозначно плюс, но айдишники встречаются в шаблоне повсеместно - в куче дочерних активити, и надо по всем ним проходиться и менять на вызов по коду.
Помню, 2 года назад на техноволне был доклад про новый bitrix framework, который уже был более приближен к best practice. Однако когда докладчикам задали вопрос, где можно этот прототип посмотреть, и когда вообще хотя бы примерно ждать его выхода, те начали кивать в сторону маркетологов и обратной совместимости.
Если использовать коробку, то ряд описанных в статье проблем можно решить кастомизацией. Например, подписаться на событие перед добавлением контакта, проверять, привязана ли компания и в случае чего возвращать ошибку.
У нас ребята для дополнительного функционала используют где-то бизнес-процессы, где-то универсальные списки, где-то события.
То же самое и с отчётами. Стандартный механизм отчётов весьма топорно сделан, но кто мешает написать свой?
Как оказалось, метод, описанный в данной статье, не является панацеей — например, когда речь заходит об ORM, где файлы и классы имеют разное именование, в местах вызова нужных классов будут всплывать ошибки.
Поэтому спасибо за указанные слабые места, уважаемые комментаторы, действительно, лучше всё-таки использовать для этих целей Composer
antares_me, я в курсе про список пользователей. Если вы внимательно читали статью, то в начале я об этом упоминал:
Переход в соответствующий раздел в админке требовал определенного количества времени, что не сильно меня радовало, поэтому было решено найти более быстрый способ авторизации.
@gluck69, согласен, но считаю, что одно другому не мешает. По крайней мере, если бы я не написал этот пост, то не открыл бы для себя компонент http-foundation от symfony. Да и вообще начал приглядываться к этому фреймворку детальнее
Достаточно собрать сущность инфоблока с помощью wakeUp и вызывать getList без джойна таблицы свойств, по крайней мере, явного:
А дальше всё стандартно...
За освещение проблемы однозначно плюс, но айдишники встречаются в шаблоне повсеместно - в куче дочерних активити, и надо по всем ним проходиться и менять на вызов по коду.
нет, похоже, заглохла тема...
Помню, 2 года назад на техноволне был доклад про новый bitrix framework, который уже был более приближен к best practice. Однако когда докладчикам задали вопрос, где можно этот прототип посмотреть, и когда вообще хотя бы примерно ждать его выхода, те начали кивать в сторону маркетологов и обратной совместимости.
А жаль, задумка-то хорошая была...
Для сайта согласен, хотя многие компании хотят бус, руководствуясь политикой импортозамещения.
Но мы обычно разрабатываем для коробки Битрикс24, кроме того, не всем компонентам бывает нужен композит
Если использовать коробку, то ряд описанных в статье проблем можно решить кастомизацией. Например, подписаться на событие перед добавлением контакта, проверять, привязана ли компания и в случае чего возвращать ошибку.
У нас ребята для дополнительного функционала используют где-то бизнес-процессы, где-то универсальные списки, где-то события.
То же самое и с отчётами. Стандартный механизм отчётов весьма топорно сделан, но кто мешает написать свой?
Поэтому спасибо за указанные слабые места, уважаемые комментаторы, действительно, лучше всё-таки использовать для этих целей Composer
Битрикс с композером в принципе не особо дружит, почитайте документацию, приходится через какие-то странные телодвижения его подключать.
marvin255, спасибо за адекватный и развёрнутый комментарий!
Про генератор модулей краем уха где-то слышал, но не сталкивался, не поделитесь ссылкой?
И да, про spl_autoload_register я тоже знаю, просто забыл его упомянуть в статье ))
Спасибо за интересную идею, надо подумать, как запихать туда компонент выбора пользователей )