Цитата:
Сообщение от
ax_mct
У них еще есть SAP Web IDE который для тех кому надо просто без всяких MVC.
Я не очень разбираюсь в сапе, но знакомый АБАП-программист несколько лет назад говорил, что можно те же самые формы на АБАПе запускать в вебе.
Причем даже отладчик есть в веб-версии.
Цитата:
Пришлепка эта по ходу как EP для AX2012 что было бы идеальным вариантом и для AX вместо превращения в один EP. Но судя по тому как CDX за 8 месяцев перевел SAP в Cloud, там как то все более вариативно и один web интерфейс возможен.
Клауд != веб интерфейс. Отдельный дополнительный web-native интерфейс нужен для ограниченного количества сценариев.
Цитата:
Тут вопрос кому. Пришедший со стороны web-программист посмотрит на все это дело и сделает все сбоку на каком либо варианте ASP.NET. Просто потому что иначе карму себе испортит.
Он не сможет это сделать. Для большинства разработок нужно что-то менять в бекенде. Как и в SAP, я думаю.
Цитата:
А типичному AX/D365FO программисту не нужна расширяемость front-end. Ему расширяемости X++ для полноты жизни и так хватить.
Иногда расширяемость нужна, я яталкивался с задачами, когда надо было вкручивать сводные таблицы, диаграммы ганта, карты поселка. И это у меня весьма ограниченный опыт внедрения и работы на клиенте.
Цитата:
Согласен что от добавления front-end расширяемости в текущий "web" фрэймворк D365FO ни жарко ни холодно. Она этому фрэймворку не нужна.
Как и в SAP, если есть унаследованное приложение, то фремворк не может не поддерживать его. А там свой лейаут и так далее.
Цитата:
Но в то же время думаю что использование какого-то общего и более стандартного web-framework было бы более разумно, с разделением front-end и back-end программирования. Если бы с самого начала развития AX7 типичный MS CRM программист мог делать front-end, а типичный AX программист back-end программирование то это было бы более дальновидно.
Я думаю, для типичного сценария это не надо. Для добавления поля в простую форму вообще достаточно драг энд дропнуть EDT в табличку и поле группу полей.
Фронтендовской логики в типичном случае не очень много.
Для того сценария, что вы приводили, можно написать фронтэнд сбоку.
Если бы с самого начала был стандартный веб фреймворк, мы бы заставили X++ кодеров заниматься дизайном или нанимать дополнительных фронтэндщиков а для типичной задачи это оверкилл.