XDTO - это просто, часть 3
Краткое содержание предыдущих серий
Первый две статьи были посвящены обзорной экскурсии по XDTO, введению в схемы XML, базовым операциям по импорту их в конфигурацию.
Собственно, статьи:
При написании данной статьи, я столкнулся с небольшой дилеммой. Я планировал описать устройство объектов и их взаимодействие с теоретической точки зрения. Но в комментариях мне обоснованно пояснили, что лучшее объяснение - это пример. Языки программирования начинают учить с "hello world" и уже потом лезут в теоретические дебри. Я с этим согласен. Когда нет конкретного примера, который можно пощупать, то вникать в кучу слов неинтересно, да и трудно. Я попробую совместить в статье кусок теории, но подкрепить его небольшим примером кода, показывающим описанные в статье моменты. Возможно, получится сумбурно, т.к. я пока не до конца понимаю структуру будущей статьи.
И все-таки, начнем не с кода, а опять, с описания компонентов подсистемы XDTO.
Компоненты подсистемы XDTO
Нам не повезло с документированием подсистемы. Совершенно непонятно - откуда у нее растут ноги и с чего начинать работу с ней. Давайте попробуем разобраться.
Как я уже говорил ранее, в основе всего лежит модель данных - перечень прикладных типов, которыми мы будем оперировать при работе с XDTO. Каждый объект XDTO создается фабрикой, которая умеет создавать объекты тех типов, которые содержатся в модели данных фабрики. Итак, есть четко выделенные понятия - модель данных, фабрика, объект. Что в начале - курица или яйцо?
Пакет XDTO
Самый "первичный" объект во всей подсистеме, это пакет XDTO. Именно от него, растут все связи. С него и начнем. Почему он? Потому, что модель данных - это ни что иное, как массив пакетов XDTO. А модель, как я уже говорил - это наше все.
Что такое пакет и что такое ветка ПакетыXDTO
Все наверняка видели в дереве конфигурации ветку ПакетыXDTO. Что это и зачем оно нужно? Оказывается, оно в-общем-то и не нужно :) Использовать XDTO можно и без описания пакетов в этой ветке. Наличие пакетов, зашитых в конфигурацию совсем не обязательно. Ветка эта нужна для совсем определенного круга прикладных задач. По большому счету - вспомогательное средство работы с XDTO.
Теперь, еще раз основной тезис:
Фабрика может создавать объекты только тех типов, которые входят в модель данных этой фабрики.
Каждая конфигурация уже содержит заботливо созданную платформой фабрику, которая умеет создавать все объекты, описанные в модели данных текущей конфигурации. Какие это объекты? Это все те, которые прошиты в платформе (о них потом) и те, которые создал разработчик конфигурации (XDTO-прообразы всех справочников, документов, перечислений и т.п.).
Данная автоматически созданная фабрика, доступна в коде, как глобальная переменная с именем ФабрикаXDTO.
Все пакеты, перечисленные в ветке "ПакетыXDTO" включаются в модель данных конфигурации. Это значит, что глобальная фабрика конфигурации может создавать объекты тех типов, которые описаны в данных пакетах. Например, это позволяет использовать наши собственные объекты совместно с платформенными - можно включать наши объекты в стандартные "СпискиЗначений" и "ТаблицыЗначений".
Устройство пакета
Рассмотрим пакет поближе: пакет представляет собой логически цельный набор типов. У этого набора типов обязательно есть пространство имен, позволяющее уникально идентифицировать пакет. Если вернуться к схемам XML, то пакет - это схема. С рядом допущений, конечно, но тем не менее, ближайший "не 1С-овский" аналог пакета - это схема XML.
Пакет включает в себя описания типов бизнес-объектов, которыми мы собираемся оперировать. Типы бывают простые и составные, об этом мы уже говорили ранее. Кроме того, пакет содержит вспомогательные средства трансляции имен переменных с языка XML на язык 1С:Предприятия и обратно (см. статью 2).
При разработке пакетов я не пользуюсь стандартным редактором, поэтому, наверное, не буду его описывать. Во-первых, боюсь чего-то напутать, во-вторых, он на 90% дублирует понятия из собственно схем XML. Если вы знаете, как в принципе сделать схему (например в Liquid), то работа со стандартным редактором, скорее всего, не вызовет сложных вопросов.
Что более важно, так это то, какие понятия пакет XDTO привносит в обиход программиста, использующего XDTO. Понятия следующие:
- ТипЗначенияXDTO
- ТипОбъектаXDTO
- ЗначениеXDTO
- ОбъектXDTO
- СписокXDTO
Мы говорили о том, что типы бывают простыми и составными. Так вот, простой тип, это ТипЗначенияXDTO, а ЗначениеXDTO, это, собственно, значение этого простого типа. Как тип и экземпляр типа. Тип значения - "Число", экземпляр типа - "5". Тип значения - "Строка", экземпляр типа - "Привет". С объектом XDTO все то же самое, но применительно к составному типу.
Со списком сложнее. Если какому-либо свойству в том или ином типе задана верхняя граница, отличная от единицы, то это значит, что данное свойство может повторяться в объекте несколько раз. Таким образом, СписокXDTO представляет собой способ манипулирования множеством объектов заданного типа.
Если мы посмотрим в стандартный редактор пакетов, то увидим строгое разделение на "Типы значений" и "Типы объектов".
Встраивание пакетов в конфигурацию
Проще всего, при использовании собственных бизнес-объектов XDTO встраивать свои пакеты в конфигурацию. Это позволит не заморачиваться с созданием собственной фабрики.
Сразу скажу, что создание собственной фабрики, это очень просто, но описывать этот процесс - долго. В результате, описание и рассусоливание теории выглядит в три раза страшнее, чем собственно, создание новой фабрики. Поэтому, создание фабрик отложим на потом, а сейчас, будем пользоваться стандартной фабрикой.
Процесс встраивания пакета описывался в предыдущей статье. Сейчас, хочется закрепить следующий момент: в глобальном контексте есть переменная с именем ФабрикаXDTO и типом ФабрикаXDTO. Эта фабрика - автоматически создается платформой и включает в себя все типы самой платформы, плюс типы прикладных объектов конфигурации, плюс те пакеты, которые добавлены в ветку "ПакетыXDTO" дерева метаданных. Эта фабрика ничем особенным не отличается, при желании вы всегда можете создать такую же вручную.
Масло масляное
Здесь, на мой взгляд, следует отметить, что подобная конструкция, очень неудачный ход со стороны разработчиков платформы. Скорее всего, преследовалась цель сделать XDTO более удобным (автоматически создать все нужные объекты), но получилось на мой взгляд, мешанина из непонятных (и к тому же одинаковых) названий.
Мне кажется, ошибкой было создавать глобальную переменную. Глобальные переменные это почти всегда плохо. Кроме того, она носит название, совпадающее с ее типом. Вроде все нормально, но в голове каша.
Я очень не люблю, когда имена переменных совпадают с их типами. Звучит ужасно:
ТаблицаЗначений = Новый ТаблицаЗначений;
Массив = Новый Массив;
То же получилось и с фабрикой. Это такой объект, который нужен, мягко говоря, не каждую секунду работы программы. Люди годами пишут под 1С, даже не касаясь каких-то там фабрик. Зачем нужна семантика постоянно висящей переменной непонятно. Лучше и правильнее было бы, на мой взгляд создать метод, что-то вроде "ПолучитьФабрикуXDTOТекущейКонфигурации()". В результате имеется четкое понимание, что мы хотим использовать конкретную системную фабрику, но имя переменной, с которой мы будем работать мы придумаем сами. Да, тип этой переменной будет ФабрикаXDTO.
В результате, документация моментально становится проще, за счет исчезновения фраз "Глобальный объект "ФабрикаXDTO" с типом "ФабрикаXDTO"".
Что-то мы отвлеклись.... Имеем то, что имеем, а именно - глобальный объект, фабрику, которая умеет создавать объекты наших собственных типов. Поехали дальше!
Сериализация XDTO
Вот то, что призвано сделать нашу жизнь лучше, но, иногда, делает ее сложнее. Сериализация и десериализация, это сама цель создания вообще всей этой замороки с XDTO. Ведь что мы хотим делать? Мы хотим передавать объекты куда-либо и получать их обратно. Все объекты в конечном итоге превращаются в XML. Получается, что все, что нам нужно - это автоматическая запись некоторого бизнес-объекта в XML и чтение его обратно. Вот здесь, на этом самом месте, нужно провести жирную красную линию и разделить два отдельных механизма. Первый - это создание объектов XDTO и их сериализацию в/из XML. Второй - получение из XDTO объектов прикладного языка: строк, ссылок, дат и т.п.
Итак, жирная красная линия:
| Механизм | Что делает | Название операции |
| ФабрикаXDTO | Создает объекты XDTO и записывает их в XML. Читает XML и создает из него ОбъектыXDTO. | XML-сериализация |
| СериализаторXDTO | Читает ОбъектыXDTO и превращает их в объекты встроенного языка 1С. Выполняет обратную операцию преобразования объекта встроенного языка в ОбъектXDTO. | XDTO-сериализация |
Приведенной табличкой хотелось донести одну очень важную мысль: ФабрикаXDTO ничего не знает о метаданных конфигурации, и вообще о конфигурации. Для нее нет ни ссылок, ни таблиц значений, ничего, связанного с прикладными типами среды исполнения 1С. Фабрика оперирует только XML-типами. Эти типы похожи на "родные" и их легко спутать, т.к. они описывают те же самые объекты, но в терминах XML. Тем не менее, важно понимать, что это именно разные объекты. XML-документ, содержащий таблицу значений и универсальная коллекция ТаблицаЗначений - это разные вещи. Фабрика знает только про XML.
Сериализатор XDTO - это как раз связующее звено между средой исполнения языка и фабрикой. Он знает, как прочитать узлы XML (свойства объекта XDTO) и как их интерпретировать, превращая XML в объект среды исполнения.
Конечно, такое вот кричащее разделение с красными линиями, это немного лукавство. Один механизм не имеет смысла без другого, они тесно переплетены. Тем не менее, обратите внимание на колонку "Что делает". Разница в действиях принципиальна. Платформа же, пытается скрыть от нас, неразумных, данную принципиальность и автоматически выполняет XDTO-сериализацию тех типов, которые она умеет преобразовывать из языка в XDTO и обратно. Например, платформа знает, как превратить тип XDTO xs:string в Тип("Строка"), а xs:dateTime в Тип("Дата"). Платформа также знает, как превратить тип "{http://v8.1c.ru/8.1/data/enterprise/current-config}CatalogRef.Сотрудники" в Тип("СправочникСсылка.Сотрудники"), при условии, что в конфигурации есть такой справочник.
Автоматическое преобразование возможно только для типов-значений. Иными словами, платформа автоматически выполняет XDTO-сериализацию простых типов, когда мы работаем с объектом XDTO. Рассмотрим пример:
Пусть есть пакет XDTO, в котором есть тип "КарточкаСотрудника". Этот тип имеет свойства:
- Сотрудник ({http://v8.1c.ru/8.1/data/enterprise/current-config}CatalogRef.Сотрудники)
- ЛичныйНомер (xs:string)
Все свойства типа КарточкаСотрудника являются простыми, с точки зрения платформы. Поэтому, работая с объектом XDTO мы можем присваивать им значения напрямую из языка:
// Создаем новый объект XDTO с типом "{urn:my-namespace}КарточкаСотрудника".
xdtoКарточка = ФабрикаXDTO.Создать(ФабрикаXDTO.Тип("urn:my-namespace","КарточкаСотрудника"));
// простое присваивание, на самом деле, "за кулисами" выполняет превращение объекта языка 1С с типом "СправочникСсылка.Сотрудники" в объект XDTO с типом "{http://v8.1c.ru/8.1/data/enterprise/current-config}CatalogRef.Сотрудники".
xdtoКарточка.Сотрудник = Справочники.Сотрудники.НайтиПоНаименованию("Иванов");
// Объект с типом "Строка" автоматически превращается в ЗначениеXDTO с типом "xs:string"
xdtoКарточка.ЛичныйНомер = "12345";
Для объектных типов все немного сложнее. Там нельзя присвоить объект языка напрямую в объект XDTO. Для такого превращения нужен Сериализатор. По сути - сериализатор - это алгоритм, который сможет превратить один объект в другой. Для платформенных объектов этим занимается глобальный СериализаторXDTO. Для наших собственных - такой алгоритм мы должны написать сами. Чудес не бывает. Если надо передать куда-то XML-документ определенного формата, то наполнять его данными мы будем самостоятельно, свойство за свойством, вручную.
Поскольку, автоматическая сериализация для типов-объектов не выполняется, то обращение "через точку" даст нам ОбъектXDTO, а не готовое значение платформы.
Чистый XDTO без сериализации
Если мы хотим получить из объекта xdtoКарточка само ЗначениеXDTO личного номера, а не значение, сериализованное в готовую "строку 1С", то необходимо вызвать метод "ПолучитьXDTO". В этом случае, будет возвращен запрошенный объект.
xdtoЗначение = xdtoКарточка.ПолучитьXDTO("ЛичныйНомер");
Сообщить(xdtoЗначение.Тип()); // Выведет имя типа XDTO, с пространством имен и всеми делами.
Список XDTO
Помимо классов ЗначениеXDTO и ОбъектXDTO существует также СписокXDTO. Список позволяет оперировать коллекциями из объектов первых двух классов.
Список получается, когда для какого-либо свойства объекта установлена верхняя граница, отличная от нуля. Число показывает максимально возможное количество элементов списка. Если граница равна -1, то количество не ограничено.
Списки тоже пытаются упрощать жизнь посредством автоматической XDTO-сериализации значений. Это очень хорошо, но надо знать, в каком случае она выполняется, а в каком - нет.
Во-первых, в синтакс-помощнике не написано, что список можно обходить с помощью итератора Для Каждого Из... На самом деле, это работает. При обходе через итератор, либо через метод СписокXDTO.Получить(Номер), получаемое значение будет сериализованным. Т.е. для списка ссылок будут получаться уже готовые ссылки 1С, а не объекты XDTO.
У списка есть также метод ПолучитьXDTO, который позволяет обойти список, получая сами значения XDTO, без выполнения сериализации.
ФабрикаXDTO
Класс ФабрикаXDTO представляет собой единственное средство превращения файлов XML в ОбъектыXDTO и обратно. При этом, фабрика следит за тем, чтобы создаваемые объекты строго соответствовали заявленной модели данных (схеме XML). Если мы попытаемся наполнить ОбъектXDTO чем-то не соответствующим схеме, то произойдет исключение времени выполнения.
Давайте взглянем на фабрику поближе:
Свойство "Пакеты"
В начале статьи мы говорили, что модель данных - это массив пакетов XDTO. А фабрика представляет собой "пользователя" модели. Поэтому, свойство "Пакеты" - это массив пакетов, которые составляют модель данных фабрики.
Обращение к коллекции пакетов возможно либо по числовому индексу, либо по URI пакета. Разумеется, возможен перебор с помощью Для Каждого Из...
Метод Тип()
Метод получает на вход полное имя типа (URI пакета + Имя типа в пакете) и возвращает объект ТипЗначенияXDTO или ТипОбъектаXDTO, для типов-значений и типов-объектов соответственно. Эти объекты сродни классу "Метаданные" в языке Предприятия. С их помощью можно узнать метаданные типа XDTO. Длину, маску, "списковость", перечень свойств и т.п.
Метод Создать()
Основной и любимый метод. Позволяет фабрике оправдывать свое название. Конструирует объект XDTO того типа, который ему передали.
Методы ЗаписатьXML()/ПрочитатьXML()
Позволяют отправить ОбъектXDTO в поток XML, и соответственно, прочитать поток XML и создать на его основании ОбъектXDTO. Методы чтения/записи имеют несколько особенностей.
Чтение XML
Как и в любом другом случае работы с XML, у нас всегда есть некоторый источник XML. Это может быть текстовый источник, документ DOM или поток FastInfoset. Что приятно, источник неважен, они взаимозаменяемы. Чтобы создать объект XDTO нужно спозиционировать источник XML на начало узла, который является объектом и вызвать метод ФабрикаXDTO.ПрочитатьXML().
И вот здесь, кстати, зарыта небольшая собачка. Пример:
// Переменная ЧтениеXML - некий источник XML
ОбъектXDTO = ФабрикаXDTO.ПрочитатьXML(ЧтениеXML);
Перед Вами - самый простой способ считывания объекта. Объект гарантированно считывается и возвращается в виде ОбъектаXDTO. Проблема в том, что если в файле прямо не указан тип объекта с помощью атрибута "xsi:type" (~90% случаев), то объект получит тип anyType(). Свойства этого объекты будут нетипизованы, получить внятные метаданные объекта будет проблемно (хотя и можно). Тем не менее, мы получим полноценный объект XDTO. Если нам не нужно сильно "копаться" в нем, а например, просто передать еще куда-то, то лучше способа не найти. Не надо ни пакетов, ни схем, вообще ничего. Читаем XML, получаем Объект.
Но, как правило, нам, все-таки, нужно, чтобы объект был вполне определенного типа, чтобы знать, что от него ожидать (например, смело обращаться к свойству "ЛичныйНомер", зная, что в объекте оно есть).
Для этого в методе ФабрикаXDTO.ПрочитатьXML есть второй параметр - тип объекта. В этом случае, при чтении, Фабрика проверит, что поток XML соответствует схеме данных и создаст новый объект, если XML корректен. В противном случае, создание не выполнится. Соответствие проверяется по всей строгости валидации схем XML. Если, скажем, длина какого-то реквизита не совпадает с требуемой, будет ошибка чтения.
После чтения, Фабрика передвигает позицию в потоке XML дальше, на следующий за объектом узел.
ЗаписьXML
Запись выполняется несложно:
ФабрикаXDTO.ЗаписатьXML(ПотокЗаписи, ОбъектXDTO);
Вот тут тоже есть пара нюансов. Во-первых, объект XDTO при записи в XML должен быть размещен в каком-то узле. По умолчанию, объект помещается в узел, с именем, соответствующем имени типа. Например, объект типа "Message" помещается в узел элемента "Message". Имя узла можно поменять, с помощью параметров "ЛокальноеИмя" и "URI" метода ЗаписатьXML().
Во-вторых, в разделе "чтение" я говорил, что в XML может быть записан специальный атрибут "xsi:type". В этом случае, тип объекта будет явно указан в XML и при чтении платформа сможет создать объект нужного типа, а не anyType. Для того, чтобы в файле было явно указано - к какому типу принадлежит объект - нужно задать последний параметр "УказаниеТипа" метода записи. Если тип не задать, то ничего страшного не будет. Корректно прочитать объект мы можем, указав ожидаемый тип в методе "ПрочитатьXML" (см. выше).
Собственная фабрика и модель данных XDTO
Чтобы фабрика могла работать, ей нужна модель данных. Модель данных позволяет фабрике создавать объекты. Не забываем, что модель данных, это просто массив пакетов.
Как и любой другой объект языка 1С, фабрика создается вызовом конструктора с помощью оператора "Новый ФабрикаXDTO". Закавыка заключается в передаче правильных параметров конструктору.
Конструкторы
Конструкторов два. Оба сводятся к тому, что фабрике нужен массив пакетов, чтобы у нее была модель данных. Если мы посмотрим в синтакс-помощник на конструктор объекта ФабрикаXDTO, то мы увидим вариант "На основании модели типов". Там же читаем: "Модель представляется в виде объекта XDTO, имеющего тип XDTO {http://v8.1c.ru/8.1/xdto}:Model".
Первое впечатление от прочитанного - "что-что-что? какой-какой матери?" Но если разобраться, все не так страшно. Нам говорят о том, что нужно создать объект XDTO с типом Model, объявленным в пространстве имен http://v8.1c.ru/8.1/xdto. Получается, чтобы создать свою фабрику, я должен создать ОбъектXDTO, описывающий модель данных, а потом этот объект "скормить" конструктору "Новый ФабрикаXDTO()".
Ну хорошо, создавать объект нужного типа мы умеем:
Модель = ФабрикаXDTO.Создать(ФабрикаXDTO.Тип("http://v8.1c.ru/8.1/xdto","Model"));
А дальше-то что делать? Не знаю, как вы, а я в документации ответ на этот вопрос не нашел. Зато, я нашел, как выгрузить из конфигурации массив пакетов в виде готовой модели. Этим-то мы и займемся.
Забегая вперед скажу, что этот объект Model просто описывает все то, что вы видите в Конфигураторе, когда создаете пакеты XDTO. Объект Model содержит перечень пакетов package, каждый пакет имеет перечень типов-значений, типов-объектов, словом все, что Вы видите в боковой панели "Свойства" конфигуратора - все отражается в этом объекте Model.
У ФабрикиXDTO есть замечательные методы "ЭкспортМоделиXDTO()" и "ЭкспортСхемыXML()". Методы замечательны тем, что возвращают готовые объекты, которые можно "скормить" конструкторам Фабрики.
Выгрузка модели данных
К статье приложена внешняя обработка "ВыгрузкаПроизвольнойМоделиДанных". Данная обработка показывает все-все пакеты XDTO, которые содержатся в стандартной глобальной фабрике. Можно увидеть там ряд интересных вещей. Например, пакеты управляемого приложения http://v8.1c.ru/8.2/managed-application/logform, и даже http://v8.1c.ru/8.2/managed-application/modules. В управляемом режиме платформа ведет обмен клиент-сервер с помощью механизма XDTO. Поэтому, все служебные типы, нужные для обмена, в фабрике представлены. Не спрашивайте только, что они делают - понятия не имею :). Давайте рассмотрим ее устройство.
1. Перечень пакетов
// Получаем список, в котором отметим флажками пакеты, которые нам нужны.
Для Каждого Пакет Из ФабрикаXDTO.Пакеты Цикл
ВыгружаемыеПакеты.Добавить(Пакет.URIПространстваИмен);
КонецЦикла;
2. Выгрузка нужных пакетов в файл
// Формируем массив URI пакетов, отмеченных в списке
ВыбранныеПакеты = Новый Массив;
Для Каждого ЭлементСписка Из ВыгружаемыеПакеты Цикл
Если ЭлементСписка.Пометка Тогда
ВыбранныеПакеты.Добавить(ЭлементСписка.Значение);
КонецЕсли;
КонецЦикла;
// По массиву URI создаем объект {http://v8.1c.ru/8.1/xdto}:Model
Объект = ФабрикаXDTO.ЭкспортМоделиXDTO(ВыбранныеПакеты);
Запись = Новый ЗаписьXML;
Запись.ОткрытьФайл(ИмяФайла);
// Запись с явным указанием необязательных параметров.
ФабрикаXDTO.ЗаписатьXML(Запись,Объект,"Model","http://v8.1c.ru/8.1/xdto",,НазначениеТипаXML.Явное);
Запись.Закрыть();
Теперь, у нас есть модель данных, а значит, мы можем создать собственную фабрику:
ЧтениеXML = Новый ЧтениеXML;
ЧтениеXML.ОткрытьФайл(ИмяФайла);
// Внимание. Второй параметр - ТипXDTO не указываем, т.к. перед этим явно записали его в файл. Все же рекомендуется ВСЕГДА указывать второй параметр, чтобы избежать некорректной трактовки XML файла. Нельзя гарантировать, что внутри файла тип указан.
ОбъектModel = ФабрикаXDTO.ПрочитатьXML(ЧтениеXML);
НоваяФабрикаXDTO = Новый ФабрикаXDTO(ОбъектModel);
А теперь все то же самое, но проще.
Как легко и просто создать свою фабрику XDTO не прибегая к созданию Model? Можно воспользоваться вторым конструктором и создать фабрику на основе схемы XML. Второй конструктор фабрики хочет получить НаборСхемXML на входе. Сделаем ему этот набор:
Чтение = Новый ЧтениеXML;
Чтение.ОткрытьФайл(ИмяФайла);
ПостроительDOM = Новый ПостроительDOM;
Документ = ПостроительDOM.Прочитать(Чтение);
ПостроительСхем = Новый ПостроительСхемXML;
Схема = ПостроительСхем.СоздатьСхемуXML(Документ.ЭлементДокумента);
НаборСхем = Новый НаборСхемXML;
НаборСхем.Добавить(Схема);
Фабрика = Новый ФабрикаXDTO(НаборСхем);
От автора
Я все-таки предпочитаю первый способ, т.к. он более родной и дает более гибкое управление создаваемой фабрикой. Вспоминаем отличия Схем XML от Пакетов (статья №2). Кроме того, мне кажется, что первый способ должен работать немножко, но быстрее, т.к. нет промежуточных преобразований из текста XML в модель через DOM и построитель схем. Специально быстродействие не замерял, так что могу и ошибаться.
Создавая собственные фабрики XDTO, делаю так:
- Создаю в Liquid нужные схемы
- Загружаю их в пустую конфигурацию-болванку
- Выгружаю пакеты приведенной выше обработкой
- Полученные файлы кладу в макет обработки, которой требуется создавать фабрику
- При выполнении обработки создаю схему:
ЧтениеXML = Новый ЧтениеXML;
ЧтениеXML.УстановитьСтроку(ПолучитьМакет("Модель").ПолучитьТекст());
ОбъектModel = ФабрикаXDTO.ПрочитатьXML(ЧтениеXML);
НоваяФабрикаXDTO = Новый ФабрикаXDTO(ОбъектModel);
Кстати, конфигурацию-болванку можно заменить кодом из второго способа создания фабрики.
-
Создаем фабрику вторым конструктором (на основании НабораСхемXML)
-
Из этой фабрики выгружаем Model методом ЭкспортМоделиXDTO().
-
Получаем Model, для сохранения в макете и использования в боевом режиме.
Обещанный пример кода
К статье прилагается пример конфигурации, демонстрирующий все, что было описано в предыдущих (и текущей) статьях. Основные моменты расписаны в комментариях к коду.
Конфигурация представляет собой гипотетический пример обмена данными по зарплате сотрудников. В конфигурации демонстрируются способы применения всех упомянутых аспектов XDTO. Обратите внимание, что в коде идет обращение к объектам XDTO по русскоязычным именам. В файл же попадают англоязычные узлы XML. Это как раз демонстрирует возможность разного представления в XML виде и в XDTO виде.
Учебный пример поставляется за символическую цену. Стоимость в 2-3 раза ниже 1 часа работы специалиста по 1С. Информация, которую можно почерпнуть из примера является в каком-то роде уникальной, ее больше нет нигде в Сети. Сэкономленное время на изучение XDTO стоит намного больше.
Заключение
На данный момент, мне кажется, что ключевые моменты механизма XDTO рассмотрены. Все, что осталось - это уже более сложные вещи, которые лучше разбирать на конкретных примерах. Задавайте вопросы с примерами в любом удобном виде (комментариях, личной почте), попробую ответить.
Спасибо за интерес к моим статьям.
