http://dev.1c-bitrix.ru/community/blogs/keymnsk-blog-dv/ ru http://backend.userland.com/rss2 Tue, 07 Apr 2026 00:25:16 +0300
Не так давно мы закончили писать первую версию документации по смарт-процессам и новому API CRM. Спасибо Роберту и его команде за оперативную публикацию.

Документация тут - https://dev.1c-bitrix.ru/api_d7/bitrix/crm/crm_new_api.php и https://dev.1c-bitrix.ru/api_d7/bitrix/crm/dynamic/index.php

Если её внимательно прочитать (а ещё лучше - ознакомиться с исходным кодом), то станет понятно, что у разработчиков появляется возможность внедриться очень глубоко в API "малой кровью" (без модификации ядра). Мы почти не ставили final у классов и методов, только местами.

Однако наличие этой возможности не значит, что ей необходимо очень активно пользоваться.

Как вы знаете, мы поддерживаем обратную совместимость. Но цена этой поддержки - довольно высока. Это в буквальном смысле сковывает нам руки - нам всё время приходится держать в голове необходимость поддержания совместимости, рефакторить сильно нельзя и т.д. Код становится "закостенелым" и буквально превращается в легаси с момента выхода первой его версии.

Теперь, когда у разработчиков есть возможность наследовать классы продукта, это становится ещё сложнее. Т.к. по-хорошему, мы не можем менять даже сигнатуру protected методов.

В связи с этим большая просьба - при наследовании классов придерживайтесь рекомендаций, изложенных на этой странице https://dev.1c-bitrix.ru/api_d7/bitrix/crm/customization/index.php

Здесь я изложу их ещё раз немного другими словами
1. Не надо наследовать стандартные классы без особой необходимости вообще. Делайте это только в крайнем случае и когда вы полностью отдаете себе отчет, как и что вы делаете
2. Не надо использовать / наследовать те классы, которые в документации помечены соответствующим образом (ParentFieldManager и другие).
3. Если вы наследуете класс, ни в коем случае не меняйте сигнатуру методов добавлением новых аргументов / изменением типов возвращаемых значений и т.д. Если надо передать какие-то дополнительные данные, сделайте отдельный метод для этого
4. Не стоит слишком полагаться на структуру массивов внутри классов. При использовании делайте проверки.
5. Даже следуя этим рекомендациям можно столкнуться с тем, что после установки обновления что-то отвалится из-за каких-то изменений. Пишите тесты, тестируйте обновления не на продакшн-окружении, используйте фича-флаги.

Если после ознакомления с кодом или документацией вам что-то не понравилось - не стесняйтесь писать.


По поводу нового API для старых сущностей - будет, но не сразу. Не так давно мы сделали возможность читать данные о лидах, сделках, контактах и компаниях (выйдет в районе crm 21.800.0). Позже добавим возможность и делать изменения через новое API.

По поводу реста - доделываем прямо сейчас, будет классно.
Подробнее...]]> http://dev.1c-bitrix.ru/community/blogs/keymnsk-blog-dv/41098.php http://dev.1c-bitrix.ru/community/blogs/keymnsk-blog-dv/41098.php Fri, 09 Jul 2021 12:23:59 +0300
В следующем обновлении не будет final у классов. Но если кто-то каким-то образом унаследовался от классов с final, то после установки обновления могут быть проблемы, т.к. я поменял сигнатуру методов (добавил строгую типизацию, местами отрефакторил). Изменения больше косметические, но всё же.

Кроме этого, я добавил возможность указать своего наследника вместо стандартного класса для Document, Template, DataProviderManager, UserPermissions через событие. Переопределив Template, можно будет указать свой тип парсера (вынес в отдельный метод). Т.к. классов для парсера два, то у Docx я добавил метод
getXmlClassName, где можно будет указать своего наследника вместо DocxXml.

Некоторые просили дать возможность добавлять свои поля в стандартные провайдеры в crm. Теперь такая возможность появилась - с помощью события можно будет подсунуть своего наследника вместо стандартного провайдера. И он будет использован во всех местах, без внесения изменений в интерфейс. Ну и всегда есть вариант наследовать DataProviderManager и там делать что угодно с провайдерами и полями.

Для ArrayDataProvider и HashDataProvider добавил геттеры и сеттеры, больше не надо будет использовать рефлексию в onBeforeProcessDocument.


Ещё будет добавлена возможность использовать повторяющиеся блоки внутри ячеек таблицы, и в маркере повторяющегося блока можно будет вставить модификатор index, чтобы он размножился только один раз для определенного элемента списка (эти способы можно комбинировать).

В одном из следующих обновлений crm выйдет выбор моей компании и реквизитов в роботе создания документа, печать свойств заказа.

Документацию написал.

По срокам - вряд ли скоро, не раньше мая.
Подробнее...]]> http://dev.1c-bitrix.ru/community/blogs/keymnsk-blog-dv/the-announcement-of-updates-to-the-document-generator-2000.php http://dev.1c-bitrix.ru/community/blogs/keymnsk-blog-dv/the-announcement-of-updates-to-the-document-generator-2000.php Fri, 17 Apr 2020 09:25:02 +0300
4 октября проводил митап по генератору документов на конференции Bitrix Power.

Записи митапа нет. Митап был короткий, а презентацию я собрал довольно большую и подробную.
Возможно, кому-то будет полезно.

Там есть ответы на типовые вопросы и популярные кейсы.

Файл можно скачать тут https://dev.1c-bitrix.ru/upload/doc_gen_04_10_2019.pdf
Подробнее...]]> http://dev.1c-bitrix.ru/community/blogs/keymnsk-blog-dv/the-presentation-of-the-document-generator-to-meet-up-with-bitrix-powe.php http://dev.1c-bitrix.ru/community/blogs/keymnsk-blog-dv/the-presentation-of-the-document-generator-to-meet-up-with-bitrix-powe.php Tue, 26 Nov 2019 10:11:55 +0300