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

[mazzy]

Цитата:

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

не перепутал ли ты RunbaseProgress, RunBase, SysOperationProgress и SysOperation в этом сообщении?

Опять демагогия и опять в твоем перечне классов нет SysOperationSandbox...
Что позволяет предположить. а не перепутал ли ты с чем-то?

Ок. Расскажи свое видение картины. Только чтобы в нем обязательно был SysOperationSandbox. Просто потому что тема ветки SysOperationSandbox.

[belugin]

Цитата:

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

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 работала вместо этого и рыться в багтрекере.

[mazzy]

Макс, спасибо.

Цитата:

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

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

спасибо, что изложил свое видение.

Цитата:

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

Начнем с конца. SysOperationSandbox это часть SysOperation FW (а не обертка над) для того, чтобы выполнять синхронные запросы на клиентской стороне.

ЕСЛИ SysOperationSandbox - это часть SysOperation FW для выполнения синхронных запросов на клиентской стороне
И SysOperationSandbox отсутствовал раньше,
ТО значит ли это, что раньше синхронные запросов на клиентской стороне нельзя было выполнить?


ЕСЛИ синхронные запросов на клиентской стороне без SysOperationSandbox можно было выполнить
ТО почему это SysOperationSandbox часть фреймворка, а не надстройка над ним?

Цитата:

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

Т.е. она позволяет запустить с некоторым дефолтным UI операцию (метод сервиса). Судя по перекрестным ссылкам она используется не только изнутри SysOpFW но и напрямую.

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

собственно в этом и вопрос - почему за информирование пользователя в данном классе отвечает ВЫЗЫВАЮЩАЯ сторона, а не сам класс, как было в старые добрые времена.

Цитата:

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

Давай я пофикшу твое утверждение как я его понимаю:

Да, Спасибо.

Не буду придираться к деталям. Спрошу про одно - ты просто перевернул мое восприятие:

Цитата:

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

1. (атрибуты наследуются) вместо наследования - не наследуемые атрибуты

КАК!?
Давай уточню вопрос.
Пусть есть два класса. Bar - потомок Foo. Foo помечен атрибутом.

class MyClassAttibute extends Attribute { }
class MyMethodAttibute extends Attribute { }

[MyClassAttribute]
Class Foo {

    [MyMethodAttribute]
    void myMethod();
}

Class Bar extends Foo {

    void myMethod();
}

Значит ли это что в Аксапте класс Bar тоже помечен атрибутом?
Значит ли это что в Аксапте метод класса Bar тоже помечен атрибутом?

[belugin]

Цитата:

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

Значит ли это что в Аксапте класс Bar тоже помечен атрибутом?
Значит ли это что в Аксапте метод класса Bar тоже помечен атрибутом?

Тут я, наверное, ошибся. Они наследуются вместе с методами (т.е. tесли метод не перекрыт, SysOP выведет параметры как у предка), но не наследуются у классов и перекрытых методов.

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

Наверное мне пока не попадалась задача перекрыть параметр но при этом не меняя метку.

[belugin]

Цитата:

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

ЕСЛИ SysOperationSandbox - это часть SysOperation FW для выполнения синхронных запросов на клиентской стороне
И SysOperationSandbox отсутствовал раньше,
ТО значит ли это, что раньше синхронные запросов на клиентской стороне нельзя было выполнить?


ЕСЛИ синхронные запросов на клиентской стороне без SysOperationSandbox можно было выполнить
ТО почему это SysOperationSandbox часть фреймворка, а не надстройка над ним?

Мне трудно посмотреть что было на этом месте в Ax2012, пока мое видение такое:
эта часть была не оформлена. В Ax7 ее выделили в статический метод (extract method) и стали использовать снаружи недокументировав.

То есть эта штука используется самим sysop fw И предоставляет возможность снаружи вызывает один частный случай (не оборачивая старый способ вызова а наоборот, выделив его).

[mazzy]

А могу я все-таки еще один вопрос по твоему тексту?

Цитата:

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

Начнем с конца. SysOperationSandbox это часть SysOperation FW (а не обертка над) для того, чтобы выполнять синхронные запросы на клиентской стороне.

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

ведь сейчас любой, абсолютно любой код X++ выполняется на сервере.
что ты имеешь в виду?

[belugin]

Цитата:

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

ведь сейчас любой, абсолютно любой код X++ выполняется на сервере.
что ты имеешь в виду?

Я просто процитировал XML коммент, я думал эта штука была сделана до того, как все ушло на сервер (либо автор называет forms engine клиентом).

Есть еще одна гипотеза, что в связи с тем, что сейчас аксапта считает что если операция выполнялась дольше какого-то времени, она зависла и паникует, то пришлось делать некий Sandbox чтобы делать синхронно с точки зрения вызова, но асинхронно с точки зрения движка. В-общем, надо посмотреть что там внутри.

[mazzy]

Цитата:

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

я думал...
...пришлось делать некий Sandbox...

вооот.
и возвращаемся к началу темы

Цитата:

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

мне одному кажется, что логика Sandbox вывернута наизнанку?