API для записи объектов метаданных из стороннего приложения

[aliczin]

просили issue - создадим

суть в следующем - сейчас библиотеки представляет модель для чтения - то есть сериализации из файлов в объект.
а хочется запись - то есть изменять объекты MD и десериализовать в файлы.

помимо всяких Ынтырпрайз сценариев использования есть один важный открытый сценарий

в Github встроили https://github.com/features/codespaces
да и не только туда - многие развертывают VSCode как отдельный сервис для Bitbucket/Gitlab, чтобы позволить кодировать прямо в браузере

Такому сервису понадобится не только запись BSL языка, но еще и изменение метаданных.

То есть "слева" будет дерево метаданных с командами - на панели.

для указанных сценариев и придется делать "запись", помимо чтения.
У меня сейчас в работе пилотный сценарий "Из DWH на Oracle в 1С метаданные" - но это уже другая история, хотя функциональность будет таже.

[asosnoviy]

@otymko переведи плз этот поток сознания в осмысленную таску =)

[aliczin]

@asosnoviy конечно-конечно - больше осмыслений. Больше ищузов и больше коментов. ;-).

А существует какой-то формат по которой ты/Вы определяете осмысленность НЕосмысленность таски ? Лех забей - будет PR - сразу станет все понятно ;-)

[otymko]

@aliczin кейсы мне понятны. Что-то подобное для VSC предполагалось делать. Но описанная задача выше - она глобальная и даже трудно прикинуть трудозатраты на нее. Я бы начал со следующего:

• Выбор минимального кейса, например отрисовка дерева метаданных "крупными" мазками.
• Возможность в дереве метаданных выше менять порядок, с отражением изменений в формате edt / original.
• Сразу вырисовывается вопрос по взаимодействию VSC / Monako / Codespaces. Т.к. они на другом стеке (ts и т.п.), нужно будет организовывать между ними обмен. Через JSON RPC например.

Пример более сложный сходу на стороне текущего проекта не получится сделать - т.к. многих вещей не хватает в моделях метаданных.

[nixel2007]

я вообще не уверен, что взаимодействие с пользователем имеет смысл делать на стороне mdclasses. само апи сериализации - да, вполне. а отприсовка и UI/UX - это явно ide-specific задача, и для панели нужно делать отдельный плагин/доработку существующих плагинов. mdclasses все же довольно низкоуровневая библиотека.

эндпоинты для таких операций можно реализовать в виде protocol extension для bsl ls, дабы не утяжелять библиотеку. а panel api - уже задача плагина

[aliczin]

@nixel2007 именно API - в MDClasses именно API

[johnnyshut]

Текущий MVP
Сейчас в writer’е используются только те поля, которые уже есть в модели (name, synonym, codeSeries, checkUnique и т.п.). Всё остальное пишется дефолтами в конвертерах.

Вариант: JAXB + XSD
Можно писать XML через классы, сгенерированные по XSD-схемам платформы 1С (JAXB и т.п.). Тогда вывод будет на 100% совместим с выбранной версией платформы. Схемы берут из ресурсов платформы или выгружают через описание/XDTO в 1С.

XMLReader = New XMLReader;
XMLReader.SetString(
  "<Model xmlns=""http://v8.1c.ru/8.1/xdto"" xmlns:xs=""http://www.w3.org/2001/XMLSchema"" xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"" xsi:type=""Model"">
  |  <package targetNamespace=""http://v8.1c.ru/8.3/MDClasses"" elementFormQualified=""true"" attributeFormQualified=""false"">
  |  </package>
  |</Model>"
);
XDTOModel = XDTOFactory.ReadXML(XMLReader);
MyXDTOFactory = New XDTOFactory(XDTOModel);

---

Фиксирую, чтобы не потерять.

[johnnyshut]

Частично, требования из текущего issues закрыл в новом проекте.
Считаю, что в рамках md-classes изначальное требование не реализовать, иначе нужно много чего начать читать.