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

[gl00mie]

Цитата:

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

Цитата:

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

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

Зависит от того, что значит "изменять функциональность". В разрешенных местах можно вроде. Драйвера поддерживаются в рамках одного поколения API.

Очень интересная аналогия с OS и драйверами. Обратимся к истории...
Драйверы в виндах были, думаю, изначально, однако, я не видел живьем версии до 3.1 - это 1992 год выпуска. Но там не то, что драйвер, а любое приложение могло поставить OS в колленно-локтевой упор. В качестве точки отсчета для корпоративного рынка я бы взял WinNT 4.0 - это 1996 год выпуска. Однако, и там с драйверами было не все хорошо, частенько приходилось видеть синий экран смерти, потому что IRQL not less or equal, кроме того, PnP-шность (аналог возможности установки разных расширений D365O сбоку без конфликтов) хромала на обе ноги. Как-то полегче стало в Win2000 (соответственно, 2000-й год выпуска) и совсем хорошо - в WinXP (2001-й год). Где-то тогда же пошла тема с подписанными Microsoft'ом драйверами, которые вместе с железом проходили сертификационное тестирование (аналог сертификации решений для AppStore).
Таким образом, флагманскому продукту Microsoft, над которым трудилось, думаю, куда больше народу, чем сейчас над D365O, понадобилось 4-5 лет (а то и 8-9, если считать с Win3.1), чтобы выкристализовалось API драйверов и подходы к их написанию, позволившие сторонним разработчикам начать клепать действительно совместимые между собой, устанавливаемые side-by-side драйверы сети, дисковых устройств, фильтры файловой системы, etc. И это при том, что архитектура OS была достаточно хорошо проработана уже во времена WinNT 4.0. Стоит ли тогда удивляться, что сейчас, спустя всего полтора года (с ноября 2016) после первого релиза AX7/D365O, с Extension'ами еще не всё так радужно, как пытается представить mfp?

[ax_mct]

Прокрастинируя перед задачей которую неоценил раза в три, поинтересовался как у других.

Опять таки язык Apex. Хотелось бы чтобы MFP сравнивал с ним и другими, прежде чем заявлять что X++ самый самый. Особенно если речь о лидерах рынка за которыми идет гонка и которых в то же время как бы не существует.

https://developer.salesforce.com/pag...mming_Language

Apex Features and Functionality
In addition to the essential capabilities of running on demand in a multi-tenant environment, Apex Code brings a number of other features that greatly expand the power developers have in using the Force.com platform and in the range of applications they can build.

Apex Code and event model. Apex Code can be tied to the execution of the platform, enabling developers to exert fine-grain control over an application. When thinking about the Apex code, it’s useful to consider the analogy of stored procedures and triggers, since fundamentally the language is tied to behaviors on the data, as opposed to providing a higher level UI language or representation. Hence developers can tie Apex Code into almost every aspect of an application’s behavior: overriding the behavior in existing buttons, creating a new button, manipulating the control of a custom link, programming the control of an inline s-control, or even overriding the behaviors associated with a related list and data.

Consider an app that enables the user to create a new lead in Force.com by clicking the save button to commit that record to the database. With Apex code, developers can create and execute code residing on salesforce.com’s server to intercede just after the button is clicked. The code might check for any duplicate records, and if it finds any, implement a data quality scenario that notifies the user. Otherwise, the record commits to the database as is normally the case. (See Apex Code Example above.)

Transaction control. Because Apex Code is closely bound to Force.com data, developers can readily add transactional features to their applications. For example, if one user is referencing a field while somebody else is trying to delete it, the system is aware of the conflict. Apex Code also features data commits and rollbacks, which are especially important when working across multiple objects.

Packaging, re-use and Web services. Apex Code uses a packaging model similar to that of Java, in which reusable packages of code can be invoked from each other or from within triggers. Unlike Java, however, Apex is not object oriented in the sense that those packages can be modified through inheritance. Significantly, any method defined in a package can optionally be automatically exposed as a Web service, and thus can be invoked via the SOAP API or directly through the AJAX toolkit.

Performance, scalability and upgrades. Because Apex Code runs on demand, scalability, compatibility and maintenance issues are salesforce.com’s responsibility, not yours. Apex-developed applications can scale indefinitely to support additional users, without your having to deploy additional servers. Applications potentially run faster because a single query can obtain information from multiple objects.

When newer versions of Force.com and the Apex code itself are introduced, your code is never rendered obsolete. Force.com ensures backward compatibility by maintaining processor-specific versions of Apex virtual machines, which in turn correspond to the API. As a result, your code continues to operate without modification.

Apex Code and the AppExchange. Apex Code can be packaged along side custom objects, S-controls and other platform features, allowing developers to redistribute their Apex Code-enhanced apps via the same AppExchange directory available today.

[MikeR]

Цитата:

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

Прокрастинируя перед задачей которую неоценил раза в три, поинтересовался как у других.

Опять таки язык Apex. Хотелось бы чтобы MFP сравнивал с ним и другими, прежде чем заявлять что X++ самый самый. Особенно если речь о лидерах рынка за которыми идет гонка и которых в то же время как бы не существует.....

Вот вот, именно. Я так это понимаю, что в следующей версии AX7-D365 уже добавят таки Node.js или хотя бы Angular. Так как у Salesforce это уже есть.
Сидят такие индо менеджеры и меряются у кого платформа по круче будет.
Ну как это в D365 нет современных форков!
...
А на всех остальных на@рать. Привыкнут.
Главное, что бы либидо индо менеджера было удовлетворено.

[trud]

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

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

[Stitch_MS]

[pitersky]

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

[ax_mct]

Цитата:

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

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

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

Цитата:

Сообщение от 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]

Цитата:

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

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

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

[ax_mct]

Цитата:

Сообщение от 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]

Цитата:

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

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

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

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

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

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

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

[Ivanhoe]

Stitch_MS, так все, теперь официально не нужно добавлять Ent edition. И аналог NAV получил свое отдельное название Business Central.

[Ivanhoe]

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

[ax_mct]

Цитата:

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

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

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

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

[gl00mie]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

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

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

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

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

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

Цитата:

Сообщение от 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 для более реальной ниши на стыке двух продуктов.

[trud]

Цитата:

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

Как обьяснить клиенту который прочитал данную статью MFP что мы не можем сделать на web интерфейсе то что он хочет
когда его жена вчера на web-конструкторе типа wix.com сделала себе сайт,

Ну кстати посмотрел тут видео из whats new, MS там прямо раскрывает этот вопрос
т.е. те кто хотят по старинке сложным языком кодят в X++
а новый подход успешных людей - это мышкой создавать Power apps, из AX брать только данные

https://dynamics.microsoft.com/en-us...#release-notes

[ax_mct]

Кстати о древнем SAP и к вопросу о туториале сравнить трудоемкость в D365FO и где-то еще.

Полазил по CDX и посмотрел что они там делают и предлагают. Так вот SAP в Cloud он не хуже AX7 с точки зрения front-end расширений.

Вот практически туториал, сомневаюсь что трудозатраты выше чем в D365FO.
https://experience.sap.com/fiori-design-web/grid-table/

https://experience.sap.com/fiori-design-web/sap-fiori/

https://www.sap.com/uk/developer/top...velopment.html

https://www.sap.com/uk/products/fior...t-capabilities

SAP Fiori, SAP Web IDE.

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

[belugin]

Я, честно, не понял, о каком сценарии идет речь. Что значит раширяемость фронтенда без бекенда и как это происодит в SAP. Вы можете пример привести? User story? Конерктная задача и как она решается в вашем любимом интрументе одним фронтендом?

[ax_mct]

Цитата:

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

Я, честно, не понял, о каком сценарии идет речь. Что значит раширяемость фронтенда без бекенда и как это происодит в SAP. Вы можете пример привести? User story? Конерктная задача и как она решается в вашем любимом интрументе одним фронтендом?

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

В качестве примера. Есть у нас ввод заказа. Есть операторы telesales. По сути для них D365FO не ERP, а рабочее место telesales. У них требования одно-оконное приложение, максимальная скорость ввода заказа в целом, подтягивание всевозможной информации по клиенту и его предыдущим заказам. И все это в том UI к которому они привыкли в другом приложении. Весь back-end должен быть в кнопке "Submit" и может быть 1-2 быстрых запросов сервера перед этим.

Цитата:

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

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

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

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