ax7: SysOperationSandbox - пример использования. почему именно такая архитектура?

[belugin]

Еще в Ax2012 убрали ссылки с сервера на клиент (до этого был распределенный сборщик мусора, который был медленный и доставлял проблемы). А progress на сервере был объектом, который не знал про клиентский и клиентский его периодически опрашивал, насколько я помню.

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

[mazzy]

Цитата:

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

Еще в Ax2012 убрали ссылки с сервера на клиент (до этого был распределенный сборщик мусора, который был медленный и доставлял проблемы). А progress на сервере был объектом, который не знал про клиентский и клиентский его периодически опрашивал, насколько я помню.

Но это к делу не относится...

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

Цитата:

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

Разумеется в части из них UI надо выводить самостоятельно. Потому, что они примитивы.

Почему это "разумеется"? Кому надо?

Почему разработчики сделали примитивы?
Есть ли не примитивный фреймворк в Аксапте?

===================
Ребяты, это раньше можно было говорить "это в САПе так" и глазами так УУУУ
https://www.youtube.com/watch?v=IrdVZ32Wl4M
теперь в части UI аксапта на рынке джаваскриптов, джейквери, ангуларов и прочих реактов.

"разумеется" "они примитивы" и прочие УУУУ не канают, когда можно вгуглить вопрос, добавить jQuery и получить кучу ссылок с ответами и примерами как это уже сделано.

для примера погуглите "jQuery progress bar".

===================
так вот, вопрос собственно - ПОЧЕМУ изо всех возможных вариантов реализации, разработчиками аксапты выбран именно такой "кучерявый наизнанку"?

опять же таки! "кучерявый наизнанку" в мире программирования UI уже есть - React. Это настолько наизнанку, что поначалу оторопь берет. Но "наизнанку" там обладает своей логикой и приводит к тому, что вот там, там и там становится намного легче. А также рендеринг на сервере.

А в Аксапте в чем плюсы "кучерявого наизнанку SysOperation"? MVC, говорите?
Но это замена одного термина другим. А в чем плюсы MVC в Аксапте?
Юнит-тестирование и моки, говорите? А в чем плюсы юнит-тестирования и моков в Аксапте, при условии, что юнит-тесты не поставляются партнерам и клиентам?
Form Adapter и Task Recorder, говорите? А не слишком ли высокая цена за то, чтобы получить только Task Recorder?

Зачем?

[macklakov]

Цитата:

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

теперь в части UI аксапта на рынке джаваскриптов, джейквери, ангуларов и прочих реактов.

Ты уже почти ответил на свой вопрос Какая из этих технологий пренадлежит MS? Даст ли использование этих подходов приемущество в патентных войнах?

[belugin]

Цитата:

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

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

Да, теоретически такая возможность есть. Не все теоретические возможности на практике реализованы.

Цитата:

Почему это "разумеется"? Кому надо?

Потому, что они примитивы. Если не надо, то можно ничего не делать.

Цитата:

Почему разработчики сделали примитивы?

Потому, что их сделать проще и вообще что-то сложное состоит из примитивов.

Цитата:

Есть ли не примитивный фреймворк в Аксапте?

SysOperation наверное (если делать полностью сервис и запускать его контроллером).

Цитата:

Ребяты, это раньше можно было говорить "это в САПе так" и глазами так УУУУ
https://www.youtube.com/watch?v=IrdVZ32Wl4M
теперь в части UI аксапта на рынке джаваскриптов, джейквери, ангуларов и прочих реактов.

При всем уважении, аксапта не является JS библиотекой а использует их. Это как сказать, что раньше аксапта была на рынке WinApi рядом с офисом и WinAmp.

Цитата:

для примера погуглите "jQuery progress bar".

Я еще добавил server side

Цитата:

А в Аксапте в чем плюсы "кучерявого наизнанку SysOperation"? MVC, говорите?

Я уже высказал свое мнение по этому поводу в соответсвующем треде.

[mazzy]

Цитата:

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

Да, теоретически такая возможность есть. Не все теоретические возможности на практике реализованы.
...
Я уже высказал свое мнение по этому поводу в соответсвующем треде.

Ясно. Спасибо, Макс, за твое очень ценное мнение.
Если собираешься продолжать в таком же духе подмены понятий, то, пожалуйста, воздержись от участия в этой ветке. Буду очень признателен.

Для тех же, кто хотел бы разобраться. Вопрос:
ПОЧЕМУ? ЗАЧЕМ сделано или не сделано именно так?

Цитата:

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

Ты уже почти ответил на свой вопрос Какая из этих технологий пренадлежит MS? Даст ли использование этих подходов приемущество в патентных войнах?

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

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

Итак, старый добрый SysOperationProgress:
* одна операция один класс
* в одном классе замешаны хранилище данных, маршаллинг данных, диалог, собственно обработка
* допускается наследование классов-обработок
* предоставляется фреймворк, от которого надо унаследовать свой класс и встроиться в фреймворк
* отлаживать надо один класс
* класс полностью управляет своим состоянием, инициализацией и восстановлением параметров, отображенем себя в UI. В частности, сам занимается отображением своего прогресса и прочим информированием пользователя о своем состоянии.


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

по сути изменений два:
1. вместо наследования - не наследуемые атрибуты
2. вместо все-в-одном - группа очень тесно связанных классов
3. вместо обычного класса - обязательно сервис

Супер-новая штука в ax7 SysOperationSandBox (не обсуждался):
* класс-обертка для фреймворка SysOperation
* позволяет написать один вызов, чтобы вызывать обработку фреймворка SysOperation произвольный статический метод произвольного класса.
* отображает на экране инфо-окно специального вида.


===================
Собственно какие альтернативы были:
например, миксины
вместо атрибутов (и рефлекшн) пойти в interface и наследование от интерфейсов.
другими словами, написать интерфейсы для datacontract, service, controller

не требовать, чтобы это были отдельные классы, а позволить создавать любые классы, которые имплементируют интерфейсы. в старой доброй аксапте уже начали ходить в эту сторону. См. runbase, enumerator и прочие. (см. скриншот ниже)

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

почему не пошли дальше?
зачем сменили курс?

===================
я абсолютно не верю в то, что между клиентом и сервером невозможно передать данные. потому что вижу примеры других систем, где эти данные вполне передаются. также вижу и аксапту с ее "новым" инфологом.
поэтому не катит.

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

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

однако вижу, что кто-то принял решение - SysOperationProgress не нужен.
лично меня абсолютно не устраивает "объяснение" в стиле "Не все теоретические возможности на практике реализованы."
Меня не интересуют ВСЕ теоретические возможности.
И возможности SysOperationProgress вовсе не теоретические.
Считаю ответ в таком стиле чистой воды демагогией.

Я хочу понять логику этого товарища (или группы товарищей) в отношении SysOperationProgress, SysOperation, SysOperationSandbox.
Я хочу понять ПОЧЕМУ?

Понять я хочу, чтобы эффективно использовать это понимание в своей работе. И сделать продукт более конкурентноспособным.

[macklakov]

Цитата:

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

Понять я хочу, чтобы эффективно использовать это понимание в своей работе. И сделать продукт более конкурентноспособным.

У меня сложилось впечатление, что разработчки и консультанты на партнерах и клиентах не рассматриваются как клиент. Поэтому язык и инструментарий делаются под нужды продуктовой команды. И поэтому ими очень неудобно пользоваться на внедрежах.
Т.е. если нужен инструментарий удобный для внедренца, его надо писать отдельно. Но т.к. удобство внедренца в приоритетах не значится, систему неожиданно изменят и инструмент придется преписывать заново. По этой причине хороших инструментов на рынке мало. И по этой причине на внедрежи в бюджет не укладываются и бывают проблемы с прохождением аудита. И поэтому продукт агонизирует. И поэтому на замену AX выстраивается линейка 365 компонент.