Вопросы про RunBase

[Wamr]

1. Есть некий серверный обработчик, который вызывается из основного меню и из формы. Один из параметров - код документа, при вызове из формы должен заполниться автоматически.
Как правильно реализовать?

2. В Tutorial_RunbaseBatch метод construct серверный. Таким образом, настройка RunOn в менюитем не играет никакой роли. Это так было задумано и считается правильным или просто так получилось в данном случаи?

[mazzy]

Цитата:

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

1. Есть некий серверный обработчик, который вызывается из основного меню и из формы. Один из параметров - код документа, при вызове из формы должен заполниться автоматически.
Как правильно реализовать?

юзать диналинк.
при вызове из меню DataSource - не заполнен.
при вызове из формы DataSource - должен быть заполнен.

чтобы юзать диналинк ничего программировать не нужно, нужно в menuitem формы указать свойство Source. Дальше Аксапта сама свяжет.

Цитата:

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

2. В Tutorial_RunbaseBatch метод construct серверный. Таким образом, настройка RunOn в менюитем не играет никакой роли. Это так было задумано и считается правильным или просто так получилось в данном случаи?

Есть технический аспект, есть идеологический.

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

Поэтому, я воспринимаю слово server в методе, как настоятельный совет следовать идеологии. Но не догму

[AndyD]

Цитата:

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

1. Есть некий серверный обработчик, который вызывается из основного меню и из формы. Один из параметров - код документа, при вызове из формы должен заполниться автоматически.
Как правильно реализовать?

Передавать через Args в main().

Цитата:

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

2. В Tutorial_RunbaseBatch метод construct серверный. Таким образом, настройка RunOn в менюитем не играет никакой роли. Это так было задумано и считается правильным или просто так получилось в данном случаи?

Так задумано.
Дело в том, что если для класса указать RunOn=Called from и создавать экземпляр на сервере, то при вызове Prompt() будет создаваться клиентская копия класса.

[mazzy]

Цитата:

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

Передавать через Args в main().

только стоит не программировать, а просто поставить свойство

[AndyD]

Цитата:

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

только стоит не программировать, а просто поставить свойство

Это зависит от задачи.
В общем случае может не быть датасорса

[Wamr]

Прошу прощения за формулировки вопросов.

1. имелся в виду "один из параметров, который выводится в диалог и пользователь может его сменить".
Я сомневаюсь, что dynalink в классах работает без программирования, а добавлять в диалог DS, чтобы с ним подвязался исходный курсор, как-то тоже "нелегкое" решение.
То что args в main принесет мне данные, я понимаю. Что дальше с ними делать? Пихать в объект через parm метод? А как к этому отнесется getLast при вызове диалога (известно как потрет нафиг)?

2. У меня было мнение, что при установке свойства класса CalledFrom и RunOn=Server на менюитем, получается диалог с пользователем на клиенте без лишнего общения с АОСом и исполнения функционала на сервере. Таким образом, мы можем управлять местом исполнения настройками менюитема. А сделав construct серверным, мы лишаемся такой возможности, не понятно что получив взамен.

[db]

Цитата:

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

Прошу прощения за формулировки вопросов.

1. имелся в виду "один из параметров, который выводится в диалог и пользователь может его сменить".
Я сомневаюсь, что dynalink в классах работает без программирования, а добавлять в диалог DS, чтобы с ним подвязался исходный курсор, как-то тоже "нелегкое" решение.
То что args в main принесет мне данные, я понимаю. Что дальше с ними делать? Пихать в объект через parm метод? А как к этому отнесется getLast при вызове диалога (известно как потрет нафиг)?

потрет. использую в таких случаях в main()
.getLast()
.parmXXX(...)
.saveLast()

[sukhanchik]

Цитата:

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

2. У меня было мнение, что при установке свойства класса CalledFrom и RunOn=Server на менюитем, получается диалог с пользователем на клиенте без лишнего общения с АОСом и исполнения функционала на сервере. Таким образом, мы можем управлять местом исполнения настройками менюитема. А сделав construct серверным, мы лишаемся такой возможности, не понятно что получив взамен.

Вообще-то - для кода один фиг - как он был вызван на сервере - при помощи установки свойства RunOn у менюитема, у класса или жестко зашит в construct.
С т.з. разработки - в целом тоже не сильно разнится - изменение свойства менюитема также относится к программированию, как и редактирование текста кода класса.

Разница лишь в том, что выставляя свойство RunOn=Server у менюитема - мы можем создать второй менюитем, не трогая класс, у которого поставить RunOn=Client.
В коде же (метод promptPrim) идет проверка - что если класс запущен на сервере и нет ограничений для создания копии себя на клиенте - то создается копия себя на клиенте. А если класс запущен изначально на клиенте - то копия класса не создается в принципе.

[Wamr]

Цитата:

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

Вообще-то - для кода один фиг - как он был вызван на сервере - при помощи установки свойства RunOn у менюитема, у класса или жестко зашит в construct.
...
В коде же (метод promptPrim) идет проверка - что если класс запущен на сервере и нет ограничений для создания копии себя на клиенте - то создается копия себя на клиенте. А если класс запущен изначально на клиенте - то копия класса не создается в принципе.

а теперь смотрим метод canSwapBetweenCSPrim
и видим, что копия делается только если класс CalledFrom

[sukhanchik]

Цитата:

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

2. В Tutorial_RunbaseBatch метод construct серверный. Таким образом, настройка RunOn в менюитем не играет никакой роли. Это так было задумано и считается правильным или просто так получилось в данном случаи?

Цитата:

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

а теперь смотрим метод canSwapBetweenCSPrim
и видим, что копия делается только если класс CalledFrom

Согласен. Но наличие серверного construct никак не связано с настройкой runOn у класса. Т.е. да, согласен - что создание копии на клиенте - связано со свойством RunOn у класса. Но с т.з. создании копии без разницы - что побудило ее создать - свойство RunOn у менюитема или серверный construct

[sukhanchik]

Цитата:

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

Прошу прощения за формулировки вопросов.

1. имелся в виду "один из параметров, который выводится в диалог и пользователь может его сменить".
То что args в main принесет мне данные, я понимаю. Что дальше с ними делать? Пихать в объект через parm метод? А как к этому отнесется getLast при вызове диалога (известно как потрет нафиг)?

Цитата:

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

потрет. использую в таких случаях в main()
.getLast()
.parmXXX(...)
.saveLast()

Обычно я всегда задаюсь предварительно вопросом - а нужно ли мне этот параметр сохранять? Если параметр сохранять не нужно - то в методе unpack() на этот конкретный параметр можно поставить условие - если параметр пустой - то его "распаковывать", если нет - не "распаковывать". Хорошо подходит, если параметр - курсор. Плохо подходит - если параметр - енум или какое-то значение, которое может быть пустым вполне осознанно.
Если параметр сохранять нужно - то тогда вопрос - а что первичнее - сохраненное или заданное значение?
На самый крайний случай - можно делать совсем просто. Кто сказал, что наследник runBase должен быть серверным? Пусть он будет клиентским. А вот метод run можно запустить и на сервере.

static void main(Args _args)
{
     RunBaseClass runClass;
     RunBaseClass runClassServer;
     runClass = new RunBaseClass();
     if (runClass.prompt())
     {
           runClassServer = RunBase::makeObjectOnServer(classidget(runClass));
           runClassServer.unpack(runClass.pack());
           runClassServer.parmXXX(runClass.parmXXX());  // Или еще как-то проинициализировать параметры
           runClassServer.run();
     }
}

См. \Classes\SysDataExportExcel\export

[db]

Цитата:

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

Обычно я всегда задаюсь предварительно вопросом - а нужно ли мне этот параметр сохранять? Если параметр сохранять не нужно - то в методе unpack() на этот конкретный параметр можно поставить условие - если параметр пустой - то его "распаковывать", если нет - не "распаковывать". Хорошо подходит, если параметр - курсор. Плохо подходит - если параметр - енум или какое-то значение, которое может быть пустым вполне осознанно.
Если параметр сохранять нужно - то тогда вопрос - а что первичнее - сохраненное или заданное значение?

То ли я не понял что ты этим хотел сказать, то ли все не слишком просто как кажется
Что значит не сохранять? Класс может переходить с клиента на сервер и обратно. Класс можно запустить в пакетную обработку. И как оно будет жить все если что то там не полностью сохраняется?

[sukhanchik]

Цитата:

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

То ли я не понял что ты этим хотел сказать, то ли все не слишком просто как кажется
Что значит не сохранять? Класс может переходить с клиента на сервер и обратно. Класс можно запустить в пакетную обработку. И как оно будет жить все если что то там не полностью сохраняется?

Не сохранять - означает - что вызов класса с использованием сохраненного значения параметра не планируется. Отказ от сохранения может быть реализован как отказ от загрузки, а не напрямую отказ от сохранения.
Класс сам по себе не переходит между сервером и клиентом. За это отвечает программист.
Кстати - заметь - я не отказываюсь от сохранения. Я корректирую загрузку.
В пакетную обработку класс может уходить. Дык это же никому не мешает.

[db]

Цитата:

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

Не сохранять - означает - что вызов класса с использованием сохраненного значения параметра не планируется. Отказ от сохранения может быть реализован как отказ от загрузки, а не напрямую отказ от сохранения.
Класс сам по себе не переходит между сервером и клиентом. За это отвечает программист.
Кстати - заметь - я не отказываюсь от сохранения. Я корректирую загрузку.
В пакетную обработку класс может уходить. Дык это же никому не мешает.

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

Енумы можно определять как пустые (если соответствующего значения нет) по значению 255. Завести где нито макрос/метод класса/глобальную функцию которая это будет возвращать и в нужных местах инициализировать/сравнивать. 255 не может быть у енума ни в каком случае (если не ошибаюсь, то последнее допустимое 250). Ну а присвоить в енум число ни что не запрещает. Это как раз к вопросу (видел тут некоторое время назад пост про нулевые значения на енумах и обязательность енумов в полях) что значения типа None в енумах все таки полезны

[lev]

Цитата:

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

...
Енумы можно определять как пустые (если соответствующего значения нет) по цифре 255. Завести где нито макрос/метод класса/глобальную функцию которая это будет возвращать и в нужных местах инициализировать/сравнивать. 255 не может быть у енума ни в каком случае (если не ошибаюсь, то последнее допустимое 250). ...

эээ, а если в какой нибудь из следующих версий вдруг решат увеличить максимальное число элементов в enum-е и сделают например 300? тогда такая доработка сразу внесет много лишней работы при переходе на новую версию.

[titov]

Цитата:

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

Завести где нито макрос/метод класса/глобальную функцию которая это будет возвращать и в нужных местах инициализировать/сравнивать. 255 не может быть у енума

AOT\Macros\Axd - строка #define.axdUnknownEnumValue(255) - уже есть!

[db]

Цитата:

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

Хорошо подходит, если параметр - курсор

А вот за параметры-курсоры в том виде как их обычно лабают надо вообще руки отрывать. Ибо просто суют некий курсор в класс через parm-метод, а потов run() как то его юзают/обновляют.
Мало того что за время с момента вызова диалога и до фактического запуска обработки данные в бд на которые указывает этот курсор могли поменяться ,так еще и юзер вызвав диалог на одной строчке чего либо может вернуться в форму (не закрывая диалога) ткнуть в другую строчку (по любой причине - ну мало ли что ему там приспичило посмотреть) и потом нажать ОК на диалоге. Обработка будет выполнена по другой строке со всеми вытекающими последствиями. А так как авторы подобных обработок обычно всю проверку возможности выполнения их операций вещают на enable() менюайтема то последствия бывают просто разрушительными

Это я к тому что (за исключением особо хитрых обработчиков где все вышеуказанное учетно и обдумано)

• Сохранять надо не записи а их коды, которые пакуются (JournalId. SalesId, RecId в конце концов)
• Строчки повторно искать внутри транзакции и проверять что они еще удовлетворяют условиям выполнения операции

[sukhanchik]

Цитата:

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

А вот за параметры-курсоры в том виде как их обычно лабают надо вообще руки отрывать. Ибо просто суют некий курсор в класс через parm-метод, а потов run() как то его юзают/обновляют.

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

Но если класс из кода вызывается и запись жестко выбрана в коде - то с такими ограничениями - код работать сможет корректно.
Кстати - также ж можно не только курсор передавать. Я курсор привел в качестве примера нескалярного типа данных. Это ж и экземпляр класса может быть. При желании.

[leva]

В сто пятидесятый раз попал в туже ситуацию и решил разобраться в вопросе.
Итак, изначальная постановка Wamr была: как правильно реализовать серверный обработчик (плюс который нормально будет работать в пакете) с параметрами, изменяемыми в диалоге. Само собой этот параметр будет в списке тех, которые сохраняются в pack() и поэтому если мы этот параметр parm-методом зададим он перетрётся старым значением.

Есть предложение db писать в таких случаях в main():
.getLast()
.parmXXX(...)
.saveLast()

Я так тоже делал, но такой метод мне не нравится, так как во-первых, сохраняет уже сразу после вызова, даже если мы отменим выполнение в диалоге и во-вторых, если класс сделан с запросом на QueryRun (который сохраняется в pack()), то нужно уже на этом этапе как-то его инициализировать.

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

Собственно я предлагаю такой вариант:
1. В classDeclaration добавить макрос со списком параметров, которые будут меняться в диалоге, например:

    #localmacro.ParamsList
        param1,
        param2
    #endmacro

2. В unpack() сохранять эти значения в контейнер и в случае, если метод был вызван для загрузки старых значений (определяется методом this.inGetSaveLast()) восстанавливать их, например:

public boolean unpack(container packedClass)
{
    Version version     = runbase::getVersion(packedClass);
    container   params = [#ParamsList];

    switch (version)
    {
        case #CurrentVersion:
            [version,#CurrentList] = packedClass;
            if (this.inGetSaveLast())
                [#ParamsList] = params;
            break;
        default:
            return false;
    }

    return true;
}

Таким образом, при загрузке значений клиентской копией и при создании объекта пакетного задания (в этих случаях inGetSaveLast = false) загрузится всё из упакованного контейнера, а случае запуска из меню с определёнными параметрами эти параметры не перетрутся.
Единственное надо проверить, чтобы на всех версиях аксапты параметр inGetSaveLast вёл себя одинаково. Ну и в минусы можно записать то, что этот список нужно не забывать пополнять по мере доработки класса (версионность тут вроде не нужна).

Подводных камней вроде не вижу. Что скажете?

[Logger]

2 leva
А не проще написать свой конструктор, а в нем :

static construct()
{
    ret = New runBase_...child();
    ;
    ret.getLast();
    return ret;
}

а затем в main вместо New runBase_...child()
писать
runBase_...child::construct()

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