Цитата:
Сообщение от
skuull
Не совсем понятна практическая цель сего доклада. Microsoft.Dynamics.Ax.Xpp.MetadataSupport* как замена Dict* полезна и нужна, но вот все остальное то зачем ?
не знаю точно.
подозреваю, что автор хотел рассказать обо всех способах, но из доклада выкинули вводную часть "из-за нехватки времени" )
а можно было рассмотреть:
= utilElement,
= treeNode,
= Dict*,
= SysModelStore (акс2012)
= обращение к исходному коду к xml-файлам,
= обращение к таблице с перекрестными ссылками,
= пресловутый SysModelMetaData (будь он неладен)
= работа с .net-классами из namespace Microsoft.Dynamics.Ax...
можно было привести примеры динамической генерации кода.
в акс7 - пресловутый SysModelMetaData, в недавних версиях AIF/DIXF, в ранних версиях - модуль ProductBuilder.
Независимо от этого мероприятия я поднимал тему рефлексии на форуме.
Как правильно получить элементы AOT заданной модели? В X++? В SQL? в акс2012? в акс7? А extension?
Там же можно увидеть скриншот для FleetManagement на тему "что хочется"
Там же можно увидеть пример кода от Maxim Belugin для работы с провайдером метаданных.
=============================
И что хочу сказать:
не используйте доступ к xml-файлам.
на мой взгляд это тупиковый путь. интересный, но тупиковый
1. напрямую через xml достаточно непросто получить корректную информацию про extensions, которые "добавляют" поля, индексы, методы и прочие субноды в основной объект. да, можно. но обратите внимание, что автор лихо обошел вопрос extension'ов. Хотя из дальнейшего доклада хорошо видно, что автор очень даже в курсе )
2. обратите внимание, что каталоги C:\AOSService\PackagesLocalDirectory\FleetManagement содержат не только исходный код. там куча бинарных и служебных xml-файлов.
3. Далеко не факт, что этот формат хранения останется в будущем именно таким. По крайней мере, я нигде не видел, что этот формат хотя бы документирован. И уж точно не было обещаний, что он сохранится.
4. Может быть, раскрою секрет. Но разработчики внутри майкрософта НЕ работают с каталогом C:\AOSService\PackagesLocalDirectory\. для VCS используется ДРУГОЙ каталог с немного другим форматом хранения и в котором находятся немного другой состав файлов (да,
похожий, но другой). А в C:\AOSService\PackagesLocalDirectory\ файлы деплоятся в ходе билд-процедур или отдельной процедурой.
Поэтому, копаться в C:\AOSService\PackagesLocalDirectory\ полезно также как копаться в UtilElements - появляются новые знания. Но нет никакой гарантии, что этот способ будет работать и в будущем.