|
23.05.2021, 13:47 | #1 |
Участник
|
В моем всбудораженном сознании зреет план как сделать реально обновление стандарта, не ломая партнерские решения и разработку in-house. То есть, я реально думаю и исследую вопрос о том, как можно соврешенно разным компаниям, условно говоря, коммитить в одну и ту же форму. С удвольствием читаю тут на форуме всё то, что касается Extension, увы D365FO видел только на картинках и видео-роликах. Если я это не придумаю, то это будет личный жирный минус в чашу весов о моей затее.
|
|
23.05.2021, 13:56 | #2 |
Участник
|
Цитата:
Легко. Изначально закрытая система с плагинами. В ядре закрытой системы грамотно расставлены предопределенные хуки, которые вызывают плагины по заранее определенным правилам. Формы - это как правило некие темплейты (шаблоны), в которых явно указаны места, куда плагины могут вставлять свои контролы, а хуками задаются места, куда плагины могут вставить свои обработчики. примеры: * vBulletin, на котором крутится этот форум (и вообще форумные движки) * Mantis Bug Tracker - https://www.mantisbt.org/ - интересная реализация форм с плагинами. Формы получаются такие же "механистичные", как в ранних аксаптах * FAR Manager * nginx * Gradle, NPM и другие менеджеры пакетов в общем, плагины. 2. D365FO дичайший антипаттерн. Не смотри туда. Причем у них не хватило таланта даже на то, чтобы сделать самую худшую реализацию - сделали просто гавно. 3. чтобы понять каким мог быть интерфейс D365FO, стоит зарегистрироваться и посмотреть на https://portal.azure.com/ как там реализован infolog, как реализованы гриды и детальные сведения. и прочее. как устроен портал ажура внутри - не знаю. Последний раз редактировалось mazzy; 23.05.2021 в 14:11. |
|
23.05.2021, 14:15 | #3 |
Участник
|
Есть одна проблема, которая всё усложняет -- расширение таблиц, то есть добавление в них полей. Вообще, я придумал как, но как говорит один бывший коллега "практика - критерий истины". Надо писать рабочий пример.
Последний раз редактировалось Lemming; 23.05.2021 в 14:18. |
|
23.05.2021, 14:21 | #4 |
Участник
|
Цитата:
ядро отвечает за join таблиц расширений. каждый плагин получает tableBase join tablePluginN этот способ категорически не работает с внешними генераторами отчетов и внешними потребителями данных. собственно из-за чего наследование таблиц в ax2012 и выпилили - майкрософт топил за Reporting Service вернее, внешние генераторы отчетов должны ожидать такого поведения от системы. Собственно так работают многие закрытые системы. добавлено: конечно же в системе где-то должна быть информация о плагинах, о том, какие таблицы какой плагин добавляет. эта информация должна быть доступна внешним системам. типа SysDicttionary в существующей аксапте, только намного богаче Последний раз редактировалось mazzy; 23.05.2021 в 14:32. |
|
23.05.2021, 14:42 | #5 |
Участник
|
Ты можешь привести пример алгоритма наследования на примере таблицы SalesTable или LedgerTrans, вот нам нужно туда поля добавить, у нас есть формы и отчеты, которые работают со оригинальной таблицей, что будет с ними?
|
|
23.05.2021, 17:35 | #6 |
Administrator
|
Цитата:
SalesTable SalesTable_RU (SalesTable_RU.SalesTable == SalesTable.RecId). Связь 1:1 или 1:0 (1 - SalesTable, 0 - SalesTable_RU) SalesTable_BR (SalesTable_BR.SalesTable == SalesTable.RecId) Связь 1:1 или 1:0 (1 - SalesTable, 0 - SalesTable_BR) А вот обратиться в стандартном коде к новой таблице естественно не получится. Тут уже нужен "хук", как говорит mazzy В D365FO сделали отдельный объект АОТа "Расширения таблиц" (также для форм) и дальше при билде все расширения "склеиваются" между собой и синхронизация добавляет все поля из всех расширений. При этом расширения (формально, по заявлению MS) могут линковаться при билде в абсолютно любой последовательности и нет возможности отследить их порядок (точнее MS оставляет за собой право пересмотреть порядок в любой момент времени) Из минусов - программист не имеет представление о конечном виде форм / таблиц. Т.е. форму, в которой куча расширений внесли те или иные изменения не увидеть в итоговом виде. Только если с нуля делать свою форму. Поэтому у расширений тоже есть ограничения по применению.
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 23.05.2021 в 17:39. |
|
23.05.2021, 18:40 | #7 |
Участник
|
Цитата:
Цитата:
но в отсутствие плагинов сделали как смогли - неуправляемо захадкожено и совершенно спрятано-невидимо для внешних систем. в старых аксаптах пример псевдоплагинных таблиц InventTableModule (с большими оговорками) в ax2009 типичный пример псевдоплагинных таблиц - LedgerJournalTrans в ax2012 таких псевдоплагинных таблиц уже много, поскольку пришло много разработчиков со Scala. Особенно "удались" расширения для стран (PL, BR и др.) sukhanchik привел пример для SalesTable мой же любимый пример из ax2012 - это конечно базовая таблица unitOfMeasure и таблица-расширение unitOfMeasure_W, которая содержит 2 (два!) поля. Одно из которых является ссылкой на запись в базовой таблице. Таблица-расширение была явно создана человеком, который пришел из закрытых систем с плагинами. Но этот человек не обнаружил в Аксапте никаких механизмов, которые обслуживают такие таблицы. Мало того, эта таблица-расширение появилась до того, как в аксапте появился функционал наследования таблиц (наследование таблиц был настолько непродуманным механизмом, что его выпилили прям в следующем сервис-паке, но при этом оставили свойства для настройки этого долбанного наследования) в общем, unitOfMeasure_W - типичный образчик того, как расширяют таблицы в мире закрытых систем с плагинами. Последний раз редактировалось mazzy; 23.05.2021 в 18:43. |
|
|
За это сообщение автора поблагодарили: sukhanchik (4). |
23.05.2021, 14:18 | #8 |
Участник
|
Цитата:
Сообщение от mazzy
3.
чтобы понять каким мог быть интерфейс D365FO, стоит зарегистрироваться и посмотреть на https://portal.azure.com/ как там реализован infolog, как реализованы гриды и детальные сведения. и прочее. как устроен портал ажура внутри - не знаю. |
|