mfp: X++ the most extensible language on the planet!

[ax_mct]

Quote:

Originally Posted by trud

Кстати по поводу обновлений - незаметно так вышла АХ8, обратите внимание на срок поддержки(на 1.5 года меньше чем АХ7.3)
вообще у них Whats new забавный получился
закрыли разработку, поддержка меньше, до кучи надо чтоб еще работало медленнее

https://docs.microsoft.com/en-us/dyn...tform-releases

Quote:

Originally Posted by pitersky

Бешеный принтер какой-то(((((((( Ну разве можно менять версии ERP-системы раз в два-три года?????

Я думаю если поискать комментарии разработчиков/партнеров по Windows Phone
то можно найти много общего.

Насчет производительности/скорости AX 7-8 вопрос который меня волнует уже много лет как основной судьбоносный фактор этого продукта. Понятно что все упирается в БД но просто для web очень чужеродный продукт сам по себе.

И кстати по теме, расширямость frond-end в web не менее, если не более, важнее чем в back-end. Так как пользователь работает с frond-end.

Понятно что это корпоративный web, но все хотелки клиенты думают в терминах frond-end. А пока все что видно это расширяемость X++ то есть back-end.

Мой опыт с ASP.NET forms и с AX EP (Sharepoint) в части frond-end оставил мерзкое чувство причастности к чудовищным извращениям.

[belugin]

Quote:

Originally Posted by ax_mct

Понятно что это корпоративный web, но все хотелки клиенты думают в терминах frond-end. А пока все что видно это расширяемость X++ то есть back-end.

А какой именно расширяемости вы хотите? Extensible controls недостаточно?

[ax_mct]

Quote:

Originally Posted by belugin

А какой именно расширяемости вы хотите? Extensible controls недостаточно?

Спасибо. Хороший вопрос.

http://dev.goshoom.net/en/2016/12/ex...tmljavascript/

https://docs.microsoft.com/en-us/dyn...ment-home-page

https://docs.microsoft.com/en-us/dyn...avascript-apis

Чего не хватает так это настоящего web-framework который независит от back-end или сам им органично является.

Тут у нас по сути back-end генерирует frond-end предоставляя свободу в рамках extensible control который должен использовать public javascript API.
https://mbs.microsoft.com/Files/publ...e2_07_2016.pdf

Эта концепция ASP.NET Web Forms которая не выдержала испытание временем. Можно сказать что у нас кровавый интерпрайз и скажите спасибо за то что хоть это есть, но у всех облачных конкурентов вполне себе настоящие web-frameworks где гораздо интереснее.

Главное здесь вот это
Visualforce app development will seem familiar to anyone who has built web apps.
https://developer.salesforce.com/page/Visualforce
А не как бы.. who has built windows apps. Это уже проходили.

Поэтому реальная расширяемость frond-end не может не отличаться. Если эту расширяемость нельзя сделать специализацией отдельного человека или бизнеса то считай что ее нет. Могу я продавать темы для frond-end D365FO?

[belugin]

Quote:

Originally Posted by ax_mct

Могу я продавать темы для frond-end D365FO?

В моей практике была потребность в контроле с переменным количеством колонок, но не глючным как table.

Сейчас я на досуге пытаюсь оформить monaco editor как extensible control. Но вот менять тему меня как-то еще не просили.

Наверное, это надо для каких-то public facing сценариев.

Для меня ценно что MorphX изолирует меня от браузера и мне не надо думать о том что означает this в данном конкретном месте и почему работает в хроме и не работает в IE11.

А рынок контролов вполне возможен, думаю.

[ax_mct]

Quote:

Originally Posted by belugin

В моей практике была потребность в контроле с переменным количеством колонок, но не глючным как table.

Сейчас я на досуге пытаюсь оформить monaco editor как extensible control. Но вот менять тему меня как-то еще не просили.

Наверное, это надо для каких-то public facing сценариев.

Для меня ценно что MorphX изолирует меня от браузера и мне не надо думать о том что означает this в данном конкретном месте и почему работает в хроме и не работает в IE11.

А рынок контролов вполне возможен, думаю.

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

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

Понятие темы в D365FO есть но оно очень свое и по сути только про изменение цвета. Как я понял даже layout не поменять.

В случае если бы front-end не был бы так тесно связан с back-end то было бы намного лучше. Например чистый ASP.NET MVC через что-типа бизнес-коннектора. Тогда можно было бы говорить о расширяемости front-end.

А расширяемость back-end мне кажется как некая карта для сталкеров в Зоне. С постоянно перемещающимися аномалиями и сектой сумашедших ученых.

monaco editor - интересно, посмотрел.

P.S. Справедливости ради если D365FO дойдет до популярности SharePoint то как не ругай SharePoint он есть и дает есть. Но опять таки не хватает цифр.

[ax_mct]

Quote:

Originally Posted by ax_mct

А расширяемость back-end мне кажется как некая карта для сталкеров в Зоне. С постоянно перемещающимися аномалиями и сектой сумашедших ученых.

Есть живые примеры вертикальных решений ISV которым не страшен серый волк. Люди отвечают.

Sunrise 365™ for Apparel and Footwear
https://appsource.microsoft.com/en-u...mics365website

Sunrise 365™ solutions are developed with Microsoft’s preferred extension model, rather than the
traditional overlay model. This means that within one week or less of a Dynamics 365 update, Sunrise 365 solutions are ready, tested, and guaranteed to work. Sunrise is able to achieve this through an extensive, in-house development team, so customers can be confident that each Sunrise 365 solution meets high standards of quality.

[belugin]

Quote:

Originally Posted by ax_mct

В случае если бы front-end не был бы так тесно связан с back-end то было бы намного лучше. Например чистый ASP.NET MVC через что-типа бизнес-коннектора. Тогда можно было бы говорить о расширяемости front-end.

Вы можете привести пример сценария в Dyn365FO такой расширяемости? То есть для какой потребности это надо.

[ax_mct]

Quote:

Originally Posted by belugin

Вы можете привести пример сценария в Dyn365FO такой расширяемости? То есть для какой потребности это надо.

Да, не факт что такая front-end расширяемость нужна Dyn365FO. Так как если бы у бабушки был ..., то это уже был бы дедушка.

Не всем нравится web-design от Microsoft. Полноценные темы полностью преображают продукт.

Пользователь выражает хотелки в терминах UI, в обычном web или AX, берешь и делаешь что им угодно. А в AX EP или Dyn365FO оценка и согласование front-end изменений на порядок сложней.

В целом странно что расширяемость берется только в контексте back-end.
Разработанная задняя часть это конечно хорошо. Но в условиях жесткого лица вызывает когнитивный диссонанс.

Но да, не нужен полный web Dyn365FO. Он нужен мне

[belugin]

Quote:

Originally Posted by ax_mct

В целом странно что расширяемость берется только в контексте back-end.
Разработанная задняя часть это конечно хорошо. Но в условиях жесткого лица вызывает когнитивный диссонанс.

Чего именно не хватает в extensible controls? Там же есть фронтенд часть? Бекэнд часть - это, фактически, только код который объясняет бекенду как взаимодействовать с фронтэндом. Фактически, этот код зависит только от платформы - то есть вы можете взять контрол и оформить его как отдельную незаисимую модель.

Вы говорите, что нужен какой-то независимый фронтэнд. Но зачем он нужен, мне непонятно.

Quote:

Но да, не нужен полный web Dyn365FO. Он нужен мне

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

• Фильтры по полям и связям
• Права доступа
• Кастомизация
• Сортировка

Хотелось бы ссылку на туториал.

Для каких сценариев вам нужен полный веб?

[trud]

Quote:

Originally Posted by ax_mct

Есть живые примеры вертикальных решений ISV которым не страшен серый волк. Люди отвечают.

Ну да, такие решения выглядят круто, но есть один момент - АХ сама по себе стоит денег(около 4к$ на пользователя и минимум 20 пользователей, ~ 80к).
Т.е. цена внедрения будет 80к + цена решения + стоимость адаптации.
и в ряде случаев это будет вчистую проигрывать .NET решениям, где за 80к можно получить уже готовое решение

Quote:

Originally Posted by belugin

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

Забесплатно не сделаешь, вопрос надо переформулировать, можно ли это сделать дешевле 80к. и в ряде случаев оказывается что можно, т.е. да, если MS будет продавать АХ как платформу разработки, то это будет выход

[Ivanhoe]

Кстати, да. Почему-бы не продавать как платформу разработки бизнес-приложений по вкусной цене.

[belugin]

Quote:

Originally Posted by trud

Забесплатно не сделаешь, вопрос надо переформулировать, можно ли это сделать дешевле 80к. и в ряде случаев оказывается что можно, т.е. да, если MS будет продавать АХ как платформу разработки, то это будет выход

Так, насколько, я понял ax_mct говорит о какой-то альттернативной аксапты с альтернативным фреймворком, но по той же цене.

[ax_mct]

Quote:

Originally Posted by belugin

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

• Фильтры по полям и связям
• Права доступа
• Кастомизация
• Сортировка

Хотелось бы ссылку на туториал.

Для каких сценариев вам нужен полный веб?

Реализация AX7 началась когда концепция Microsoft "Web для VB программистов" уже провалилась. Первый релиз AX7 (Feb 2016) совпал по времени с релизом ASP.NET Core.

Действительно 90% типичных задач занимают в 10 раз меньше времени в таких генераторах frond-end.

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

Пример? Любое что требует улучшения производительности, оффлайн работы и облегчения размера страниц. Я например страдал с клиентским grid в EP, сделал в итоге. Да, на уровне frond-end expert D365FO можно что хочешь через extension controls сделать. Где очередь записываться в такие специалисты?

Quote:

Originally Posted by belugin

Так, насколько, я понял ax_mct говорит о какой-то альттернативной аксапты с альтернативным фреймворком, но по той же цене.

Я себя цензирирую. Все же форум специализированный. Но, давайте представим что было бы если бы Microsoft CRM и D365FO использовали одинаковую web-платформу. Вместо нестандартной даже для Microsoft самописки.

[ax_mct]

Quote:

Originally Posted by Ivanhoe

Кстати, да. Почему-бы не продавать как платформу разработки бизнес-приложений по вкусной цене.

Нет шансов у D365FO. Причин много. Это и привязка к IIS, это и отстутствие популярного и понятного фрэймворка, отсутствие модульности в запутанном back-end. Привязка к MS SQL. И наличие океана альтернатив для web-разработки бизнес-приложений.

Были бы поумнее пустили бы AX в open-source. На одних серверных лицензиях (Windows Server, SQL Server etc) получали бы достаточно.

[ax_mct]

Quote:

Originally Posted by belugin

Хотелось бы ссылку на туториал.

Для каких сценариев вам нужен полный веб?

Наверно основной сценарий когда у пользователей ожидания сформированы другими системами в web и они, особо не подозревая о расширяемости X++,
просят такую же frond-end логику как у них где-то было.

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

TableGrid is a free, open-source Force.com library, that provides users and developers a highly customizable, native-looking, sortable, filterable, editable Grid Visualforce component.
This component can be used as an advanced, highly configurable (by developer and user) replacement of apexageBlockTables and Standard Related Lists.
https://github.com/rsoesemann/visualforce-table-grid

И рисуют в СR вражеский интерфейс с вражеской логикой.

Но реальности ради, я не вижу такой реальности. Скорее всего те же CRM программисты будут делать чистое ASP.NET обращаясь напрямую к данным D365FO. Примерно как SSRS программисты чихать хотели на X++".

Что кстати разумно и с точки зрения обновлений и апгрейдов. Игнорировать всю эту расширяемость и напрямую обращаться к данным. А бизнес-логику в T-SQL.

[AlexeyS]

Quote:

Originally Posted by ax_mct

Что кстати разумно и с точки зрения обновлений и апгрейдов. Игнорировать всю эту расширяемость и напрямую обращаться к данным. А бизнес-логику в T-SQL.

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

[gl00mie]

Quote:

Originally Posted by ax_mct

Были бы поумнее пустили бы AX в open-source. На одних серверных лицензиях (Windows Server, SQL Server etc) получали бы достаточно.

А нет задачи зарабатывать на лицензиях - есть задача зарабатывать на подписке, и вендор маниакально тащит всех за уши в Azure. Уже и Windows с D365O называет не продуктами, а сервисами, мол, оттого и обновления постоянные, оттого и подписка. Хочешь получать сервис - плати постоянно; платить перестал - доступ к сервису потерял.

[belugin]

Quote:

Originally Posted by ax_mct

Наверно основной сценарий когда у пользователей ожидания сформированы другими системами в web и они, особо не подозревая о расширяемости X++,
просят такую же frond-end логику как у них где-то было.

Получается что основная проблема, что они что-то не подозревают, и хотят то, что было раньше.

Мне кажется, первая часть проблемы решается ссылкой на документацию, а вторая справедлива для ОЧЕНЬ ограниченных сценариев (типа публичная часть или какая-нибудь мобильная) иначе придется переписывать интерфейс аксапты чтобы им угодить. Переобучить и немного допилить проще.

Quote:

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

Но реальности ради, я не вижу такой реальности. Скорее всего те же CRM программисты будут делать чистое ASP.NET обращаясь напрямую к данным D365FO. Примерно как SSRS программисты чихать хотели на X++".

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

[belugin]

Quote:

Originally Posted by ax_mct

отсутствие модульности в запутанном back-end.

Если брать только платформу, какой именно модульности не хватает? Модули есть. Отсутствет сквозная поддержка internal и неймспейсы.

[ax_mct]

Quote:

Originally Posted by belugin

Если брать только платформу, какой именно модульности не хватает? Модули есть. Отсутствет сквозная поддержка internal и неймспейсы.
...
У меня очень нет опыта работы с чихающими SSRS-программистами интересно, как они обходятся без дата провайдеров в сложных случаях.

Лично мне хватает. После 12 лет работы с продуктом. В принципе при сужении рынка количества знающих систему "как есть" в силу опыта может и хватить.

Но в ситуации роста популярности разбираться в системе будет программист MS CRM.

Аналогия с SSRS-программистами не случайна. Ни на одном из десятков проектов я не видел SSRS программиста который бы взял за труд изучить и использовать X++. Им удобнее неудобно. Они остаются чистыми SSRS программистами.

С учетом смешения продуктов, если массово AX программисты не будут переходить в Microsoft CRM, то программировать в AX будет чистый Microsoft CRM программист. А чистые ребята они не золотари как мы. Разбираться в X++ они не будут.

В принципе здесь открывается возможность аутсорса, но если можно будет достичь результата как в SSRS, не пачкаясь с X++, то будут делать как эффективней, а не как предполагается. Можно будет через T-SQL, значит будет T-SQL.

Quote:

Originally Posted by belugin

Получается что основная проблема, что они что-то не подозревают, и хотят то, что было раньше.

Мне кажется, первая часть проблемы решается ссылкой на документацию, а вторая справедлива для ОЧЕНЬ ограниченных сценариев (типа публичная часть или какая-нибудь мобильная) иначе придется переписывать интерфейс аксапты чтобы им угодить. Переобучить и немного допилить проще.

Как обьяснить клиенту который прочитал данную статью MFP что мы не можем сделать на web интерфейсе то что он хочет
когда его жена вчера на web-конструкторе типа wix.com сделала себе сайт,
а сын проходит курсы HTML и показывает современные плюшки на одном .CSS типа такого
где это просто один стиль CSS
http://www.cssplay.co.uk/menu/csspla...-css-only.html

"Ну вы же понимаете, у нас серьезная бизнес-система... Мы вот можем наследовать через аттрибуты..."

То есть мой пойнт в том что ожидания клиента уже сформированы современным web. Про SAP все знают - "даже не думай", а вот про D365FO - вряд ли. Особенно при схожести интерфейса с MS CRM.

И мне сдается что расширяемость front-end в для популярности значит не меньше чем back-end. С учетом стоимости этих расширений и нахождения специалистов.

Не исключаю того что front-end D365FO это уникальная ниша. Но возможно было бы правильней для AX программистов идти в MS CRM для более реальной ниши на стыке двух продуктов.