Вот мы и нашли этих 43 AX7 клиентов? Или это не AX7/D365?

[skuull]

Цитата:

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

Не получилось. Совсем. 90% кода ушло в оверлей App Suite. Очень грустно.

Пообщался я с этими ребятами и они говорят что МС поставил перед ними срок 12 месяцев чтобы переделать свой ISV на 100% экстеншен. Интересно это для всех ISV так или только для "избранных".

[gl00mie]

Цитата:

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

Пообщался я с этими ребятами и они говорят что МС поставил перед ними срок 12 месяцев чтобы переделать свой ISV на 100% экстеншен.

Осталось добавить "or else", как в стареньком фильме "Разрушитель"

Цитата:

Командир отряда полиции: Саймон Феникс! Ляг на землю и заведи руки за спину
Саймон Феникс: Это че за фигня? Ой, вас же шестеро, в такой аккуратненькой униформе, ой, боюсь-боюсь!..
(копы переглядываются)
Саймон Феникс: Ребята, вам что, совсем неведомо понятие "сарказм"?
Командир отряда полиции (обращается к своему планшету-помощнику): Маньяк ответил презрительным замечанием
Планшет-помощник: Приблизьтесь, повторите требование еще более твердым голосом. Добавьте слова "а не то..."

[trud]

Цитата:

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

Интересно это для всех ISV так или только для "избранных".

Думаю только для избранных, может лого какое введут.
Вопрос кто все это будет оплачивать - т.е. даже в предположении что у вас код с нулевым оверлеем(вообще ничего стандартного не перекрывает), переделка его на экстеншены это довольно большой объем работы, учитывая что тулзов для этого пока нет.
единственный плюс - появляется возможность устанавливать решение без компиляции и без исходного кода, но это какое-то сомнительное преимущество при продаже

[skuull]

Цитата:

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

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

А кто сказал что 100% оверлеинг нельзя ставить без компиляции и исходного кода?

[macklakov]

Цитата:

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

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

момент неприятный, конечно. С другой стороны, уход от концепции open source неизбежен. По своему, это даже красиво. Как VBA в Excel. У тебя есть стандартный движок, за который отвечает MS, у тебя есть API, которое позволяет к этому движку обратиться, и есть add-in, за который отвечает ISV или клиент сам.

[Logger]

Цитата:

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

момент неприятный, конечно. С другой стороны, уход от концепции open source неизбежен. По своему, это даже красиво. Как VBA в Excel. У тебя есть стандартный движок, за который отвечает MS, у тебя есть API, которое позволяет к этому движку обратиться, и есть add-in, за который отвечает ISV или клиент сам.

А баги кто будет фиксить ?
Майкрософт что ли ?
Щаз !

[AlexSD]

Цитата:

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

Вопрос кто все это будет оплачивать - т.е. даже в предположении что у вас код с нулевым оверлеем(вообще ничего стандартного не перекрывает), переделка его на экстеншены это довольно большой объем работы, учитывая что тулзов для этого пока нет.

А что нужно сделать что бы код с нулевым оверлеингом перевести на екстеншины?
Я полагаю, что ничего. Что там требуется переводить то? Все и так уже переведено.

ЗЫ. У меня есть опыт апргейда на 7-ку ISV (Demand Forecasting) с минимальным использованием стандартных таблиц и форм.И тулза - есть. Называется LCS.

[trud]

Цитата:

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

А что нужно сделать что бы код с нулевым оверлеингом перевести на екстеншины?
Я полагаю, что ничего. Что там требуется переводить то? Все и так уже переведено.

Хм, LCS насколько мне известно экстеншены не создает(или уже создает?)

самый простой пример - поля на таблице. т.е. у вас есть новое поле "A" на CustTable лежащее в кастомизации этой таблицы, вы решаете сделать по модному..

создаете новую extension модель, далее вам надо в ней создать новый объект - extension для custTable, удалить поле из CustTable, добавить его в новый extension.
как только вы сделаете это "бонусом" получите неработоспособность тулзов в Visual Studio таких как обновить дата ентити по таблице.
далее если те кто установят ваше решение кодируют используя кастомизацию в AppSuite и захотят заюзать ваши поля, тут их тоже ждет сюрприз, так как поля собственно будут недоступны из AppSuite

или есть новый метод на классе - тут вообще переделка на экстеншены может быть невозможна если внутри него вы обращаетесь к private переменным

[Vadik]

Цитата:

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

далее если те кто установят ваше решение кодируют используя кастомизацию в AppSuite и захотят заюзать ваши поля

не по фэншую же

[skuull]

Цитата:

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

самый простой пример - поля на таблице. т.е. у вас есть новое поле "A" на CustTable лежащее в кастомизации этой таблицы, вы решаете сделать по модному..

Это не очень похоже на "нулевой оверлей", может раскроите ваше понимание этого словосочетания перед тем как мы продолжим дискусию ?

Цитата:

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

.
далее если те кто установят ваше решение кодируют используя кастомизацию в AppSuite и захотят заюзать ваши поля, тут их тоже ждет сюрприз, так как поля собственно будут недоступны из AppSuite

Если вы уже стоите на шатком пути оверлеинга App Suite, такие мелочи вас не должны останавливать. Создается третья модель, котороя ссылаеться на экстеншен и предастваляет доступ к полям, а App Suite ссылаеться на нее. Все легко и немного извращенно

[trud]

Цитата:

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

Это не очень похоже на "нулевой оверлей", может раскроите ваше понимание этого словосочетания перед тем как мы продолжим дискусию ?
:

в терминах 2012 - все ваши объекты содержатся только в вашем слое(не являются перекрытиями в sys). например новые поля в sys таблицах или методы классов. в рамках 2012 это позволяло обновляться на новые версии(CU) без мержинга кода

Цитата:

Создается третья модель, котороя ссылаеться на экстеншен и предастваляет доступ к полям, а App Suite ссылаеться на нее.

Ну как бы да, такой подход безусловно "упрощает и ускоряет" работу. Да и заказчик несомненно порадуется более большим счетам за услуги разработчика.

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

идеальным вариантом конечно было бы сделать возможности изменения теми которые сейчас есть в экстеншенах(т.е. возможность менять меню, форм, каких-то св-в без перекрытия базового кода) + предложить разработчику решать - хочет ли он помещать код в отдельную DLL(в этом случае компилятор уже должен следить чтобы не было обращений к приватным переменным и прочему) или вместе с основной. зачем они сделали 2 разных по сути формата файлов изменений (кастомизацию и экстеншн) это не очень понятно
несомненный негатив от экстеншенов в том виде как они сейчас есть - это то что это другой объект в AOT с произвольным названием и визуально их наличие реализовано слабо - т.е. раньше хотя бы все эвенты было видно в AOT, теперь можно подписаться на метод, это вообще никак визуально будет не видно
как разбираться в таком коде - особенно если он изначально разрабатывался не вами - не очень понятно, на мой взгляд время проведенное за анализом будет поболее чем время за обновлением на очередной CU

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

[AlexSD]

Цитата:

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

Хм, LCS насколько мне известно экстеншены не создает(или уже создает?)

LCS сама екстеншины не создает. Но, мы говорим о ISV с нулевым оверлеингом. Екстеншины для ISV с нулевым оверлеем не особо нужны.

Цитата:

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

самый простой пример - поля на таблице. т.е. у вас есть новое поле "A" на CustTable лежащее в кастомизации этой таблицы, вы решаете сделать по модному..

создаете новую extension модель,

С полями, можно обойтись без екстеншина. По старинке, как сделали с некоторыми полями в локализации для 2012. Все кастомные поля в отдельную таблицу, связь по RecId c базовой таблицей. Такой подход продолжает работать для D365. Единственно, что придется в этом случае екстендить - это формы, что бы вывести свои поля на стандартные формы.

По поводу новой модели. Зачем создавать новую модель для екстеншинов? У ISV с нулевым оверлеем есть своя модель, добавляйте екстеншины в эту же модель с ISV.

[trud]

Цитата:

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

Но, мы говорим о ISV с нулевым оверлеингом. Екстеншины для ISV с нулевым оверлеем не особо нужны.
С полями, можно обойтись без екстеншина.
По поводу новой модели. Зачем создавать новую модель для екстеншинов? У ISV с нулевым оверлеем есть своя модель, добавляйте екстеншины в эту же модель с ISV.

я вот как раз полностью с этим согласен. мы вот создаём все изменения в модели с типом кастомизация, в которой и создаем экстеншены и прочее.

разговор собственно начался с фразы ниже, и обсуждению зачем это нужно.

Цитата:

МС поставил перед ними срок 12 месяцев чтобы переделать свой ISV на 100% экстеншен

т.е. я под этой фразой понимаю требование переноса решения в модель с типом Extension, это на мой взгляд довольно большой объем работ не дающий никаких преимуществ.
но народ кстати на яммере довольно активно этим занимает, некоторые используя подход описанный skuull, насоздавали уже по 10 моделей, зачем то они ж это делают

Цитата:

Cоздается третья модель, котороя ссылаеться на экстеншен и предастваляет доступ к полям, а App Suite ссылаеться на нее

[skuull]

Цитата:

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

т.е. я под этой фразой понимаю требование переноса решения в модель с типом Extension

Наличие типов у моделей вообще и типа "Extension" в частности для меня лично являеться больлшим открытием
Под этой фразой я имел в виду отсутствие Overlayering. Не забываем о том что ребята продают ISV и как только клиент захочет купить два разных ISV с оверлеингом App suite кто интересно будет ему их сводить? Вернее свести то не проблема, в 12 сводили и норм, но радужная картина апп стора и деплойментов 1 кнопкой из LCS рушиться к чертям

Цитата:

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

но народ кстати на яммере довольно активно этим занимает, некоторые используя подход описанный skuull, насоздавали уже по 10 моделей, зачем то они ж это делают

Мне кажется эта тема тут уже обсуждалась и не раз. Пока весь мир вокруг уменьшает coupling, придумывает всякие микросервисы и прочей дурью маються мы 20 с лишним лет валим все в один неймспейс и тычим пальцем в дураков которые создают больше одной модели.

[macklakov]

Цитата:

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

Все кастомные поля в отдельную таблицу, связь по RecId c базовой таблицей. Такой подход продолжает работать для D365.

А потом приходится устраивать пляски с бубном вокруг SQL чтобы он отрабатывал запросы в 30 таблиц в более-менее вменяемое время. И это без XDS, которую любой консультант спомощью галочки может активировать. С другой стороны, это извечная дилемма мира AX:"как совместить удобство Office с мощью SAP"

[AlexSD]

Цитата:

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

А потом приходится устраивать пляски с бубном вокруг SQL чтобы он отрабатывал запросы в 30 таблиц в более-менее вменяемое время.

Не думаю, что прям вот так сразу от одной дополнительной таблицы для одного ISV легко получится переступить порог в эти 30 таблиц сразу для всех стандартных форм.

Каждый случай нужно рассматривать отдельно. Варианты решения могут быть найдены разные. Например, для тех форм, где уже есть 25-29 таблиц, где этот порог действительно скоро будет перейден, можно стандартную форму оставить как есть, сделать свою форму для своих полей.

Короче, это не та причина, что бы перестать создавать свои таблицы.