04.04.2018, 18:20 | #41 |
Banned
|
Цитата:
Сообщение от trud
Кстати по поводу обновлений - незаметно так вышла АХ8, обратите внимание на срок поддержки(на 1.5 года меньше чем АХ7.3)
вообще у них Whats new забавный получился закрыли разработку, поддержка меньше, до кучи надо чтоб еще работало медленнее https://docs.microsoft.com/en-us/dyn...tform-releases Цитата:
то можно найти много общего. Насчет производительности/скорости 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 оставил мерзкое чувство причастности к чудовищным извращениям. |
|
04.04.2018, 18:42 | #42 |
Участник
|
|
|
04.04.2018, 20:04 | #43 |
Banned
|
Цитата:
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? |
|
05.04.2018, 09:14 | #44 |
Участник
|
В моей практике была потребность в контроле с переменным количеством колонок, но не глючным как table.
Сейчас я на досуге пытаюсь оформить monaco editor как extensible control. Но вот менять тему меня как-то еще не просили. Наверное, это надо для каких-то public facing сценариев. Для меня ценно что MorphX изолирует меня от браузера и мне не надо думать о том что означает this в данном конкретном месте и почему работает в хроме и не работает в IE11. А рынок контролов вполне возможен, думаю. |
|
06.04.2018, 04:01 | #45 |
Banned
|
Цитата:
Сообщение от 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; 06.04.2018 в 04:16. |
|
07.04.2018, 01:57 | #46 |
Banned
|
Цитата:
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. |
|
08.04.2018, 18:17 | #47 |
Участник
|
Вы можете привести пример сценария в Dyn365FO такой расширяемости? То есть для какой потребности это надо.
|
|
|
За это сообщение автора поблагодарили: DAX.Company (2). |
09.04.2018, 01:22 | #48 |
Banned
|
Цитата:
Не всем нравится web-design от Microsoft. Полноценные темы полностью преображают продукт. Пользователь выражает хотелки в терминах UI, в обычном web или AX, берешь и делаешь что им угодно. А в AX EP или Dyn365FO оценка и согласование front-end изменений на порядок сложней. В целом странно что расширяемость берется только в контексте back-end. Разработанная задняя часть это конечно хорошо. Но в условиях жесткого лица вызывает когнитивный диссонанс. Но да, не нужен полный web Dyn365FO. Он нужен мне |
|
09.04.2018, 08:50 | #49 |
Участник
|
Цитата:
Вы говорите, что нужен какой-то независимый фронтэнд. Но зачем он нужен, мне непонятно. Цитата:
Но да, не нужен полный web Dyn365FO. Он нужен мне
Хотелось бы ссылку на туториал. Для каких сценариев вам нужен полный веб? |
|
09.04.2018, 11:43 | #50 |
Участник
|
Цитата:
Т.е. цена внедрения будет 80к + цена решения + стоимость адаптации. и в ряде случаев это будет вчистую проигрывать .NET решениям, где за 80к можно получить уже готовое решение Забесплатно не сделаешь, вопрос надо переформулировать, можно ли это сделать дешевле 80к. и в ряде случаев оказывается что можно, т.е. да, если MS будет продавать АХ как платформу разработки, то это будет выход |
|
|
За это сообщение автора поблагодарили: ax_mct (10). |
09.04.2018, 11:48 | #51 |
Участник
|
Кстати, да. Почему-бы не продавать как платформу разработки бизнес-приложений по вкусной цене.
__________________
Ivanhoe as is.. |
|
09.04.2018, 12:43 | #52 |
Участник
|
Так, насколько, я понял ax_mct говорит о какой-то альттернативной аксапты с альтернативным фреймворком, но по той же цене.
|
|
09.04.2018, 16:59 | #53 |
Banned
|
Цитата:
Сообщение от belugin
Вы говорите, что нужен какой-то независимый фронтэнд. Но зачем он нужен, мне непонятно.
... Скажите мне, как веб-эксперт: если взять и плюхнуть грид на аксаптовскую форму и соединить с датасурсом. Запустить. Сколько времени надо чтобы в вашем любимом веб фреморке получить ту же самую фнукциональность включая:
Хотелось бы ссылку на туториал. Для каких сценариев вам нужен полный веб? Действительно 90% типичных задач занимают в 10 раз меньше времени в таких генераторах frond-end. При этом ничего волшебного в этой генерации нет чтобы не мог сгенерировать плагин к среде разработке. Пример? Любое что требует улучшения производительности, оффлайн работы и облегчения размера страниц. Я например страдал с клиентским grid в EP, сделал в итоге. Да, на уровне frond-end expert D365FO можно что хочешь через extension controls сделать. Где очередь записываться в такие специалисты? Я себя цензирирую. Все же форум специализированный. Но, давайте представим что было бы если бы Microsoft CRM и D365FO использовали одинаковую web-платформу. Вместо нестандартной даже для Microsoft самописки. |
|
09.04.2018, 17:23 | #54 |
Banned
|
Цитата:
Были бы поумнее пустили бы AX в open-source. На одних серверных лицензиях (Windows Server, SQL Server etc) получали бы достаточно. Последний раз редактировалось ax_mct; 09.04.2018 в 17:26. |
|
09.04.2018, 18:10 | #55 |
Banned
|
Цитата:
просят такую же 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. |
|
|
За это сообщение автора поблагодарили: Logger (0). |
09.04.2018, 20:03 | #56 |
Участник
|
Цитата:
если не нужно быстро перелопачивать сумашедшие объемы данных, то лучше обходиться без T-SQL |
|
09.04.2018, 23:18 | #57 |
Участник
|
А нет задачи зарабатывать на лицензиях - есть задача зарабатывать на подписке, и вендор маниакально тащит всех за уши в Azure. Уже и Windows с D365O называет не продуктами, а сервисами, мол, оттого и обновления постоянные, оттого и подписка. Хочешь получать сервис - плати постоянно; платить перестал - доступ к сервису потерял.
|
|
|
За это сообщение автора поблагодарили: ax_mct (5). |
10.04.2018, 08:40 | #58 |
Участник
|
Цитата:
Мне кажется, первая часть проблемы решается ссылкой на документацию, а вторая справедлива для ОЧЕНЬ ограниченных сценариев (типа публичная часть или какая-нибудь мобильная) иначе придется переписывать интерфейс аксапты чтобы им угодить. Переобучить и немного допилить проще. Цитата:
Вот нашел неидеальный но грид для SalesForce с которым пришедший в компанию
ключевой пользователь работал ранее. Но реальности ради, я не вижу такой реальности. Скорее всего те же CRM программисты будут делать чистое ASP.NET обращаясь напрямую к данным D365FO. Примерно как SSRS программисты чихать хотели на X++". |
|
10.04.2018, 08:42 | #59 |
Участник
|
|
|
|
За это сообщение автора поблагодарили: ax_mct (5). |
10.04.2018, 17:42 | #60 |
Banned
|
Цитата:
Но в ситуации роста популярности разбираться в системе будет программист MS CRM. Аналогия с SSRS-программистами не случайна. Ни на одном из десятков проектов я не видел SSRS программиста который бы взял за труд изучить и использовать X++. Им удобнее неудобно. Они остаются чистыми SSRS программистами. С учетом смешения продуктов, если массово AX программисты не будут переходить в Microsoft CRM, то программировать в AX будет чистый Microsoft CRM программист. А чистые ребята они не золотари как мы. Разбираться в X++ они не будут. В принципе здесь открывается возможность аутсорса, но если можно будет достичь результата как в SSRS, не пачкаясь с X++, то будут делать как эффективней, а не как предполагается. Можно будет через T-SQL, значит будет T-SQL. Цитата:
Сообщение от belugin
Получается что основная проблема, что они что-то не подозревают, и хотят то, что было раньше.
Мне кажется, первая часть проблемы решается ссылкой на документацию, а вторая справедлива для ОЧЕНЬ ограниченных сценариев (типа публичная часть или какая-нибудь мобильная) иначе придется переписывать интерфейс аксапты чтобы им угодить. Переобучить и немного допилить проще. когда его жена вчера на 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 для более реальной ниши на стыке двух продуктов. Последний раз редактировалось ax_mct; 10.04.2018 в 17:55. |
|
Теги |
ax8, dyn365fo, extensions, mfp |
|
|