Цитата:
Сообщение от
mazzy
Опять демагогия и опять в твоем перечне классов нет SysOperationSandbox...
Это не демагогия. При неаккуратном использовании терминов я не понимаю, понимаешь ли ты суть и просто небрежно используешь обозначения или какие-то детали от тебя ускользнули.
Судя по тому, что ты сказал
"* класс обработка (в стандарте) не занимается своим состоянием, инициализацией и восстановлением параметров, не имеет доступа к UI. В частности,
не может отображать прогресс и не может информировать пользователя о своем состоянии."
Для тебя ускользнула разница между SysOperationProgress и RunBaseProgress - то есть ты прочитал использованные термины неаккуратно и додумал их значение.
Цитата:
Сообщение от
mazzy
Ок. Расскажи свое видение картины. Только чтобы в нем обязательно был SysOperationSandbox. Просто потому что тема ветки SysOperationSandbox.
Начнем с конца. SysOperationSandbox это часть SysOperation FW (а не обертка над) для того, чтобы выполнять синхронные запросы на клиентской стороне.
/// <summary>
/// The <c>SysOperationSandbox</c> class is an internal class for running synchronous operations
/// on client side async sessions
/// </summary>
См., например, SysOperationServiceController
X++:
public final void runOperation()
{
if (executionMode == SysOperationExecutionMode::Synchronous)
{
SysOperationSandbox::startOperation(this);
}
else
{
// route through the base class to call run or
// enqueue in batch
super();
}
}
Т.е. она позволяет запустить с некоторым дефолтным UI операцию (метод сервиса). Судя по перекрестным ссылкам она используется не только изнутри SysOpFW но и напрямую.
Давай я пофикшу твое утверждение как я его понимаю:
Итак, старый добрый
RunBase (SysOperationProgress):
* одна операция один класс
* в одном классе замешаны хранилище данных, маршаллинг данных, диалог, собственно обработка
* допускается наследование классов-обработок
* предоставляется фреймворк, от которого надо унаследовать свой класс и встроиться в фреймворк
* отлаживать надо один класс
* класс полностью управляет своим состоянием, инициализацией и восстановлением параметров, отображенем себя в UI. В частности, сам занимается отображением своего прогресса и прочим информированием пользователя о своем состоянии.
Новый SysOperation (уже обсужался неоднократно):
* несколько формально и синтаксически независимых, но при этом очень сильно семантически связанных классов
сервис зависит от контракта, контракт может засисеть от UI билдера, билдер засисит от контракта, контроллер зависит от сервиса - это все декларировано
*
наследовать от базовых классов не нужно (нет базовых классов) (
кроме сервиса и UI builder)
*
встраивание во фреймворк происходит через атрибуты (и соответственно, через рефлекшн) (кроме сервиса и UI builder)
*
создание классов-наследников от собственного происходит с трудом (потому что атрибуты не наследуются) Атрибуты наследуются и перекрываются.
* [класс обработка (в стандарте) не занимается своим состоянием, инициализацией и восстановлением параметров, не имеет доступа к UI. В частности,
не может отображать прогресс и не может информировать пользователя о своем состоянии. Может отображать прогресс (см примеры использования SysOperationProgress). У обработки нет состояния а есть только параметры (контракт), параметры могут перекрыть SysPackable и управлять своей серилизации
по сути изменений два:
1.
(атрибуты наследуются) вместо наследования - не наследуемые атрибуты
2. вместо все-в-одном - группа очень тесно связанных классов
3.
(сервис это обычный класс со статическими методами) вместо обычного класса - обязательно сервис
К сожалению, в Ax7 не доделали стандартную обработку прогресса и единственный UI что для RunBase, что для SysOP FW - это бегущие точки.
Почему не доделали, вопрос сложный, надо понять над чем client team работала вместо этого и рыться в багтрекере.