daxdilip: Some info on Microsoft Dynamics AX 2014/2015 Next Major Release codenamed "Rainier" or "Rainer"

[Blog bot]

Источник: http://feedproxy.google.com/~r/blogs...namics-ax.html
==============



Источник: http://feedproxy.google.com/~r/blogs...namics-ax.html

[mazzy]

Цитата:

Features

a. Cloud Based Solutions
b. Platform independence - Browser enabled clients
c. AD Federation and more integration with Azure
d. More investments on Visual Studio (Development Environment will be VS)
e. Application Development targetting any OS through Rainier
f. No longer need to invest on Sharepoint hosting as Enterprise portal will be eliminated
g. 3 key pillars - New client, Cloud Readiness, New Development Stack
h. No RPC based communication (Atleast, now it's assured that the event logs won't get full by RPC errors which was the case with AX 2009)
i. Programming language will still be X++ but everything will be .net compiled
j. Capability to expose updatable views using OData
k. HTML 5 based Web Client so more faster and richer experience

o_O!
Что значит "Sharepoint hosting as Enterprise portal will be eliminated"?
А что будет вместо него? Просто "Browser enabled clients"?

[EVGL]

Цитата:

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

o_O!
Что значит "Sharepoint hosting as Enterprise portal will be eliminated"?
А что будет вместо него? Просто "Browser enabled clients"?

cм. пункт k

[mazzy]

это про вот такие шняшки?
DAX: Preview of Windows 8 Apps for Microsoft Dynamics AX released in Windows Store
или будет что-то другое?


по теме см. также: The Death of Reason: #wpc13 Dynamics AX Roadmap

[imir]

Цитата:

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

o_O!
Что значит "Sharepoint hosting as Enterprise portal will be eliminated"?
А что будет вместо него? Просто "Browser enabled clients"?

Возьмут двигло из DAX 3.0, назовут новой мегафичей

[fed]

Кстати - забавная метаморфоза интернет-технологий. Когда-то давно, использование тонкого клиента и HTML продвигалось как типа снижение нагрузки на рабочее место и снижение требований к каналу.
В результате - с появлением HTML5 и Ajax тонкие клиенты начали все сильнее и сильнее напоминать X Windows System, разработанную примерно 30 лет назад. Только что X Window Core Protocol заменили на комбинацию HTML5+HTTP+XMLHTTP. Возможно - потребности в пропуской способности канала и задержках слегка снизились. Но этого же можно было достигнуть и более простым способом...

[Logger]

Цитата:

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

Но этого же можно было достигнуть и более простым способом...

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

[Logger]

X++ пощадили.
Никак не ожидал.

[belugin]

Цитата:

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

Кстати - забавная метаморфоза интернет-технологий. Когда-то давно, использование тонкого клиента и HTML продвигалось как типа снижение нагрузки на рабочее место и снижение требований к каналу.

ИМХО тут ведущая роль в том, что браузеры щас существуют, наверное, даже на пылесосах - то есть упрощение развертывания. А канал используют какой есть . А Аякс, скорее, для удобства

[EVGL]

Вывод на будущее пока один: всеми силами избегать кода на формах.

[fed]

Ну просто такие тексты могут посеять панику в рядах аксаптоводов - мол аксапту переводят на хатымыэль и нам всем придется учить верстку, CSS и шарепойнту. Но на самом деле, о HTML5 надо думать как об оконном протоколе, а не о языке верстки. Разработчики на KDE прекрасно кодят свои программы даже не догадываясь об интимных внутренних особенностях X Windows Protocol. Есть надежда, что при правильном подходе, можно написать ядро, которое рендерит аксаптовские контролы (возможно - несколько измененные), в HTML5 и как-то там их отправляет в клиент оконной системы.
Есть правда сильные подозрения что MS как раз таки не сможет применить правильный подход и разработка и отладка станет еще сложнее. (Поскольку придется разбираться и в глюках Аксапты и в глюках браузера).

[Logger]

Цитата:

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

Есть надежда, что при правильном подходе, можно написать ядро, которое рендерит аксаптовские контролы (возможно - несколько измененные), в HTML5 и как-то там их отправляет в клиент оконной системы.

Вроде бы 1С что-то подобное сделала. По крайней мере они для вебклиента отдельных форм не рисуют.

Ну и у нас будет. А фигли двойную работу делать.

[EVGL]

А в SAP есть Java GUI. AX в позиции догоняющего, подход выбран радикальный, но... почему бы и нет.

[Logger]

Цитата:

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

А в SAP есть Java GUI. AX в позиции догоняющего, подход выбран радикальный, но... почему бы и нет.

А как еще можно решить проблему с пингом про которую ты писал ?
Терминальные сервера для всех и выделенный канал ?

[Wamr]

С первого взгляда на интерфейс 2012 стало ясно в каком направлении они движутся. Эти группки открывающиеся вниз по стрелочке, просмотровый грид и редактирование одной записи по нажатию кнопки - неоднократно встречались в MS-примерах использования AJAX лет 5 назад.
То есть происходит планомерная "вебизация" интерфейса. Для полноты картины только пейджинга не хватает.

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

А еще есть кросс-браузерность, которая стандартно страдает у разработок МС.

[Logger]

Цитата:

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

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

А что взамен ?
Этак вы и от Excel предложите отказаться. Но Office365 нормально живет в вебе. Куда же мы без гридов ? По-моему это что-то нереальное.

[gl00mie]

Цитата:

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

А что взамен ? Этак вы и от Excel предложите отказаться.

Взамен - четкое разделение показа грида и возможности ввода данных в гриде (отсюда, мне кажется, режимы просмотра/редактирования на формах 2012-й). Редактирование данных в гриде очень тяжко работает в веб-интерфейсе: даже если сделать 100500 полей ввода в виде таблички, все равно данные передаются в систему не в момент перехода на следующую строку, как в виндовом клиенте Аксапты, а в момент нажатия некой чудо-кнопки - все сразу. Т.е. система получает от веб-морды одномоментно хрендцать строк данных, и если в одной из них есть ошибка, то по идее отбросить надо все строки. Ведь в следующий раз от веб-морды опять одномоментно придет хрендцать строк данных, и поди там разберись, те же самые это строки, что в первый раз, только подредактированные, или же совсем новые, и если новые, то что делать со старыми?..

Цитата:

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

Но Office365 нормально живет в вебе.

Если речь про Excel в браузере, то это, мне кажется, - дырявая абстракция Там нет валидации данных каждой строки по отдельности, нет уникальных индексов по значениям колонок и еще кучи вещей, которые есть в Аксапте.

Цитата:

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

Куда же мы без гридов ? По-моему это что-то нереальное.

Это во многом - дело привычки, как иерархические справочники - для пользователей 1С. Опять же, никто ведь не говорит о том, чтобы убрать гриды совсем, говорят лишь о том, что в гриде должна быть максимум дюжина полей, а все прочее - на отдельных вкладочках, и что грид должен использоваться по большей части для просмотра данных, а редактирование каждой записи по возможности должно выполняться не на гриде, а на отдельной вкладочке, может, даже не одной. А кому хочется эксельного интерфейса, для тех есть сервисы документов: выгрузил данные в Excel, отредактировал, значения в колонках протянул, как надо, - сохранил. Только опять же система в этом случае получает одномоментно хрендцать строк данных...

[Wamr]

Цитата:

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

Этак вы и от Excel предложите отказаться

А вот это, кстати, вряд ли. Текущий тренд от МС это add-ins-ы в Excel, как раз для работы с множеством данных.
Например: MS Dax2012, MasterDataService, PowerPivot