kirovsbis
Дмитрий Белозеров

(22)

)))

Ну да, настоящие мужики терпят!!!

(16)

Спасибо как минимум за то что не поленились продумать и написать такой кусок кода Вечером я помедитирую над ним )

(19)

Цитата
Клонирование справочников(чем копировать вставить не то)? С данынми? Можно более конкретно в каким местах это может помочь на каких реальных задачах.

Попробую более детально объяснить.
В нашей конфигурации MDM есть некий эталонный справочник, он уже содержит некую общую для всех справочников такого назначения функциональность. У него содержится код в модуле объекта, модуле менеджера, есть форма элемента и форма списка. Уже неплохо
У нас возникает потребность в создании вполне конкретного справочника НСИ, например справочника "Активы". Мы заходим в конфигуратор, копируем эталонный справочник. Соответственно в полученной копии будет такой же модуль объекта, модуль менеджера, формы и т.д. Ура!
Решён ли вопрос создания справочника "Активы"? Неа.
Нам как минимум ещё нужно:

1. Изменить значения некоторых свойств этого справочника (Например Имя, Синоним)
2. Включить созданный справочник в состав нужным нам определяемых типов, планов обмена и т.д.
3. Назначить права на этот справочник для одной или нескольких существующих ролей.
4. Добавить для этого справочника нужные реквизиты.
5. Вывести эти добавленные реквизиты на уже существующую форму элемента.
6. Модифицировать запрос динамического списка в форме списка справочника.
7. Возможно ещё ряд некоторых действий.

В статье об этом написано в целом, для создания справочника "руками" была даже написана специальная инструкция, просто скопировать объект метаданных недостаточно.
Но автоматизация создания справочников это в общем то не самое главное преимущество технологии. Как ни крути, справочник то мы создаем 1 раз, и в принципе можно и потерпеть и таки произвести все манипуляции "вручную" без "всей этой матогенерации".
На практике гораздо важнее стоит вопрос сопровождения этого кода. Допустим мы нашли ошибку в одном из модулей нашего справочника НСИ. Поскольку у нас все справочники НСИ создаются копированием эталонного, то значит ошибку надо исправлять в модуле КАЖДОГО справочника НСИ, а у нас их например штук 40. Заходить в каждый и вносить изменения удовольствие ниже среднего. В нашем случае ошибку достаточно исправить в модуле эталонного справочника, выполнить пересборку и нужные изменения будут внесены ВЕЗДЕ. Т.е. кодогенерация это по-сути способ масштабировать собственную работу.

(10)

Цитата

Ну и как развитие данной тем - нужно присваивать исходным метаданным маркеры, на которые можно было бы опереться при кодогенерации - и дальше, например, решать включать или не включать это метаданное (или его часть) в итоговое решение, ну или как-то иначе модифицировать - т.е. оперировать уже не конкретными элементами метаданных - а некими общими признаками. Например, присвоив маркер "ЕстьОрганизация" как справочнику "Организация" (условно), так и измерениям регистров, и реквизитам документов "Организация", а также блокам программного кода, обращающимся к этим метаданным - то в зависимости от настройки - ведения учета по разным организациям - можно выкинуть все эти элементы из итоговой конфигурации, тем самым снизив её сложность - а значит повысив эффективность её исполнения платформой и СУБД.

Покажу на примере как мы решаем этот вопрос.
Допустим у нас есть некая "Подсистема1", которая содержит "Документ1" (причем реквизита "Организация" у этого документа изначально нет).
Мы написали "Правило1", которое переносит "Подсистему1" из исходной конфигурации в результирующую.

А ещё есть "Подсистема2", которая содержит справочник "Организации".
Мы написали "Правило2", которое переносит "Подсистему2" и добавляет в "Документ1" реквизит "Организация".

Если мы создадим сценарий генерации состоящий из двух шагов, например:

Шаг 1 по "Правилу1"
Шаг 2 по "Правилу2"

то в результате получим конфигурацию содержащую "Документ1" с реквизитом "Организация".
Но если "Шаг 2" отключить то в результате получим "Документ1" без реквизита "Организация" т.е. этот реквизит как бы "Удалится" (но правильнее сказать "не добавится"). Поэтому проблема быстрого исключения из конфигурации ненужной функциональности легко решается если изначально нужным образом спроектировать сценарий генерации.

(11)

Наверное правильнее это транслятором назвать

(10)

Спасибо за содержательный комментарий!

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

Пример:
Есть объект метаданных, например определяемый тип. Если мы зайдем в конфигуратор и в дереве метаданных выберем наш определяемый тип, а затем откроем окно свойств (Alt + Enter), то увидим существующие свойства объекта. Некоторые будут "простыми" - например "Имя" или "Синоним", другие "сложными" (или составными) - например "Тип", но всё равно это СВОЙСТВА объекта метаданных. Поэтому независимо от того меняем ли мы синоним или добавляем новый тип в состав определяемого типа (или наоборот удаляем тип из состава) мы фактически изменяем одно из свойств объекта метаданных.
Полное описание функции "ИзменитьСвойствоОбъектаМетаданных" выглядит так:
ИзменитьСвойствоОбъектаМетаданных(<Полное имя объекта метаданных>, <Имя свойства>, <Добавляемое значение>, <Удаляемое значение>
Разработчик подает на вход функции имя объекта метаданных и имя свойства, а инструмент соответственно на основе этих данных понимает как правильно интерпретировать третий или четвертый параметр.

Примеры использования функции

Сделаем справочник иерархическим:

Код
ИзменитьСвойствоОбъектаМетаданных("Catalog.ПримерСправочника","Hierarchical","true");

Добавим новый тип в состав определяемого типа (именно добавим новый, не трогая уже включенные в состав, "изменить" это не то же самое что "заменить":

Код
ИзменитьСвойствоОбъектаМетаданных("DefinedType.ВладелецФайлов", "Type", "CatalogRef.ПримерСправочника");

А можем и сразу несколько типов добавить:

Код
МассивТипов = Новый Массив; МассивТипов.Добавить("CatalogRef.ПримерСправочника1"); МассивТипов.Добавить("CatalogRef.ПримерСправочника2"); ИзменитьСвойствоОбъектаМетаданных("DefinedType.ВладелецФайлов", "Type", МассивТипов);

Цитата
Выложите инструмент, дайте попробовать. Научите в нём работать. Простые примеры, создание справочников.

Выложу, как только подготовлю версию, которую не стыдно выложить :) Про планируемые сроки уже написал.

Цитата
Если вы продаете, так и пишите - распространение на платной основе.

С моделью распространения ещё не определились, поэтому пока не знаю что ответить на этот вопрос.

(2)

Цитата
конкретно мы вам ничего не скажем, просто покажем вам картинки чтобы вы поняли какие мы крутые

Хотелось бы больше конкретики в претензиях на отсутствие конкретики Статья всё-таки написана по итогам 30-минутного доклада, в котором полноценно раскрыть тему невозможно при всём желании. Целью было донести до слушателей саму идею, плюсы-минусы, реальные кейсы применения технологии, рассказать кратко про сам инструмент и возможные проблемы использования. Если тематика интересна - могу более подробно рассказать в следующих статьях о том как оно работает, как организован сам процесс разработки, каких архитектурных принципов стараемся придерживаться при разработке, как реализуем модульность на практике.

(1)

Цитата
Jinnee - в тексте повторяется 6 раз.

Не считал, но верю Вам на слово

Цитата
Как скачать? Примеры как использовать? Платно/бесплатно ?

Инструмент нигде не публиковали пока. Изначально его разрабатывали для решения вполне конкретных собственных задач (в первоначальной постановке он назывался "механизм клонирования справочников"). Когда получили что-то более-менее работоспособное возникла мысль рассказать об этом сообществу с целью понять будет ли тема интересна коллегам (на мой взгляд технология имеет достаточно широкий потенциал для применения). Я планирую подготовить первый полноценный релиз с документацией и примерами до конца этого года. Буду признателен за конструктивные комментарии, предложения и идеи. Готов ответить на возникающие вопросы.

В своем докладе на конференции INFOSTART EVENT 2018 EDUCATION Дмитрий Белозеров рассказал о разработке инструмента, позволяющего программно работать с метаданными 1С и писать скрипты для выполнения тех же действий, которые выполняет разработчик в конфигураторе – с какими сложностями и нюансами пришлось столкнуться, и что получилось в итоге.