DeniZone: The future of X++

[belugin]

Цитата:

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

Мое имхо:
1 Не стоит трогать X++. Да редактор напоминает богомерзкий блокнот, да нет solution explorer, да все уныло, да это было сделано, когда подавляющее число разработчиков ходило в детский сад и так далее. Но он работает! Его с лихвой хватит на те бизнес задачи, которые уже реализованы.

Редактор уже сделали - см видео с channel9. по-моему он довольно хорош.

Цитата:

2 я бы пустил на расширение функционала, на красивый дизайн и удобство пользователя. Не видят пользователи окно редактора X++ и все тут.

Редактор вряд ли сожрал существенную долю ресурсов. Остального - см список сессий тут

[gl00mie]

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

Цитата:

Сообщение от Blog bot

Источник: http://blogs.msdn.com/b/mfp/archive/...-language.aspx
In Dynamics AX 2012 we are compiling X++ code to the CLR. At compile time we generate an XML representation of the pcode, which we can convert into IL. At run-time we will be executing the IL for batch jobs, service calls and RunAs constructs. (RunAs is a new method allowing you to request the X++ logic to be executed as IL.). Peter demonstrated how the performance characteristics are vastly different particular in situations with extremely many objects or extremely many methods calls.

[fed]

Цитата:

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

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

А еще реальностью стал (по моим источникам) геморрой с перезагрузкой откомпилированных сборок. То есть - либо рестарт боевого AOS, либо работа через Application Domain. Причем скорость второго режима, мягко говоря, бледно смотриться даже на фоне скорости старого интерпретатора.
Ооо - почитал твиттер Брендона:
1. Отладка на сервере возможна только через VS Debugger
2. Чтобы отлаживаться, придется включать App Domain с тормозами.
3. Если у тебя на сервере работает несколько разработчиков - опять таки только App Domain с hot-swapping.

Ооо - как новую систему полюбят все внедренцы ! Ведь теперь нельзя будет отлаживаться на боевом сервере. Придется мучительно допрашивать пользователей о том, что же они такого отмочили и потом пытаться воспроизвести на тестовом приложении. Разумеется с подъемом бэкапа БД.
Чуствую - после выхода 6ки, придется на полгодика разрешить мат на форуме...

[sukhanchik]

Обсуждение отладки на рабочей базе вынесено в отдельную тему Отладка на рабочей базе

[Logger]

Кстати, интересно, зачем им потребовалось наследование таблиц ?
Решили отказаться от мапов ?

[sukhanchik]

Цитата:

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

Кстати, интересно, зачем им потребовалось наследование таблиц ?
Решили отказаться от мапов ?

Ну мапы-то "накодили не они" . А может сделают что-то более сильное (верю в светлое будущее). Мапы в общем-то тоже.... наследование, притянутое за уши.

[mifi]

Цитата:

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

Ну мапы-то "накодили не они" . А может сделают что-то более сильное (верю в светлое будущее). Мапы в общем-то тоже.... наследование, притянутое за уши.

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

[db]

Цитата:

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

Кстати, интересно, зачем им потребовалось наследование таблиц ?
Решили отказаться от мапов ?

Пока не увидим как это реализовано (какой интерфейс к этой табличной иерархии и как она отображается в бд) можно только гадать

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

все строго имхо

дополнение:
кстати есть уже достаточно древняя и очень классная книга Фаулера и компании
"Архитектура корпоративных программных приложений"
Вопросы табличного наследования там в том числе рассмотрены

[kashperuk]

Цитата:

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

Пока не увидим как это реализовано (какой интерфейс к этой табличной иерархии и как она отображается в бд) можно только гадать

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

все строго имхо

Я думаю, что это довольно близко описывает замысел. Хотя, это мое имхо тоже

[Logger]

Интересно, а формы они наследовать не планируют ?
Я как-то разрабатывал в системе где это было. Имеет право на жизнь.

[mifi]

Цитата:

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

Интересно, а формы они наследовать не планируют ?
Я как-то разрабатывал в системе где это было. Имеет право на жизнь.

Я тоже. И система называлась Borland Delphi.
Помню, когда переходил с Delphi на MorphX, очень не хватало этого самого наследования визуальных форм. Но, поскольку в Core AX дельфистов всегда было немного, то эта идея вряд ли когда-нибудь превратится в фичу AX, увы

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

[belugin]

Цитата:

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

Интересно, а формы они наследовать не планируют ?
.

Если винмательно почитать тут:
sjakalax: DAXCONF - Patterns in building client forms & usability

то можно кое что узнать о реюзе дизайна в формах