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

[belugin]

Цитата:

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

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

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

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

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

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

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

[ax_mct]

Цитата:

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

Цитата:

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

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

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

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

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

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

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

[belugin]

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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

[trud]

Цитата:

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

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

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

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

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

Цитата:

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

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

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