Как вы думаете: смог бы Линус Торвальдс в одиночку за 20 лет полностью повторить Асапту версии 3.0?

[mazzy]

Цитата:

Сообщение от Lemming

Далее, если процесс пойдет хорошо и появятся инвесторы, предстоит сделать уже ERP, которую можно продавать в облаках и on-permise.

"инвесторам" прежде всего надо ответить на вопрос, чем ЭТО отличается от уже существующих.

я, например, отслеживаю эти
https://github.com/mazzy-ax?tab=stars&q=erp

[Lemming]

Цитата:

Сообщение от mazzy

"инвесторам" прежде всего надо ответить на вопрос, чем ЭТО отличается от уже существующих.

В моем всбудораженном сознании зреет план как сделать реально обновление стандарта, не ломая партнерские решения и разработку in-house. То есть, я реально думаю и исследую вопрос о том, как можно соврешенно разным компаниям, условно говоря, коммитить в одну и ту же форму. С удвольствием читаю тут на форуме всё то, что касается Extension, увы D365FO видел только на картинках и видео-роликах. Если я это не придумаю, то это будет личный жирный минус в чашу весов о моей затее.

[mazzy]

Цитата:

Сообщение от Lemming

В моем всбудораженном сознании зреет план как сделать реально обновление стандарта, не ломая партнерские решения и разработку in-house.

1.
Легко. Изначально закрытая система с плагинами.
В ядре закрытой системы грамотно расставлены предопределенные хуки, которые вызывают плагины по заранее определенным правилам.
Формы - это как правило некие темплейты (шаблоны), в которых явно указаны места, куда плагины могут вставлять свои контролы, а хуками задаются места, куда плагины могут вставить свои обработчики.

примеры:
* vBulletin, на котором крутится этот форум (и вообще форумные движки)
* Mantis Bug Tracker - https://www.mantisbt.org/ - интересная реализация форм с плагинами. Формы получаются такие же "механистичные", как в ранних аксаптах
* FAR Manager
* nginx
* Gradle, NPM и другие менеджеры пакетов

в общем, плагины.

2.
D365FO дичайший антипаттерн. Не смотри туда.
Причем у них не хватило таланта даже на то, чтобы сделать самую худшую реализацию - сделали просто гавно.

3.
чтобы понять каким мог быть интерфейс D365FO, стоит зарегистрироваться и посмотреть на https://portal.azure.com/
как там реализован infolog, как реализованы гриды и детальные сведения. и прочее.
как устроен портал ажура внутри - не знаю.

[Lemming]

Цитата:

Сообщение от mazzy

1.
Легко. Изначально закрытая система с плагинами.

Есть одна проблема, которая всё усложняет -- расширение таблиц, то есть добавление в них полей. Вообще, я придумал как, но как говорит один бывший коллега "практика - критерий истины". Надо писать рабочий пример.

[mazzy]

Цитата:

Сообщение от Lemming

Есть одна проблема, которая всё усложняет -- расширение таблиц, то есть добавление в них полей. Вообще, я придумал как, но как говорит один бывший коллега "практика - каритерий истины". Надо писать рабочий пример.

легко. наследование таблиц, которое вводили в ax2012, это на самом деле расширение таблиц.

ядро отвечает за join таблиц расширений.
каждый плагин получает tableBase join tablePluginN

этот способ категорически не работает с внешними генераторами отчетов и внешними потребителями данных. собственно из-за чего наследование таблиц в ax2012 и выпилили - майкрософт топил за Reporting Service

вернее, внешние генераторы отчетов должны ожидать такого поведения от системы. Собственно так работают многие закрытые системы.

добавлено: конечно же в системе где-то должна быть информация о плагинах, о том, какие таблицы какой плагин добавляет. эта информация должна быть доступна внешним системам. типа SysDicttionary в существующей аксапте, только намного богаче

[Lemming]

Цитата:

Сообщение от mazzy

легко. наследование таблиц, которое вводили в ax2012, это на самом деле расширение таблиц.

ядро отвечает за join таблиц расширений.
каждый плагин получает tableBase join tablePluginN

Ты можешь привести пример алгоритма наследования на примере таблицы SalesTable или LedgerTrans, вот нам нужно туда поля добавить, у нас есть формы и отчеты, которые работают со оригинальной таблицей, что будет с ними?

[sukhanchik]

Цитата:

Сообщение от Lemming

Ты можешь привести пример алгоритма наследования на примере таблицы SalesTable или LedgerTrans, вот нам нужно туда поля добавить, у нас есть формы и отчеты, которые работают со оригинальной таблицей, что будет с ними?

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

Из минусов - программист не имеет представление о конечном виде форм / таблиц. Т.е. форму, в которой куча расширений внесли те или иные изменения не увидеть в итоговом виде. Только если с нуля делать свою форму. Поэтому у расширений тоже есть ограничения по применению.

[Lemming]

Цитата:

Сообщение от mazzy

3.
чтобы понять каким мог быть интерфейс D365FO, стоит зарегистрироваться и посмотреть на https://portal.azure.com/
как там реализован infolog, как реализованы гриды и детальные сведения. и прочее.
как устроен портал ажура внутри - не знаю.

Сходу бросилось в глаза, что непонятно в каком порядке поля отсортированны.