SMART TALKS 110: Metadata, abstract syntax tree and X++ best practice rules. Part 1

[mazzy]

Цитата:

Сообщение от 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 - появляются новые знания. Но нет никакой гарантии, что этот способ будет работать и в будущем.