Вопросы про 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

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

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

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

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

[db]

Цитата:

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

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

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

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

[sukhanchik]

Цитата:

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

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

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

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

[lev]

Цитата:

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

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

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

[db]

Цитата:

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

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

в замену одного числа в макросе/методе который это 255 определяет. Да и вероятность расширения енумов мала микроскопически

Дополнение. Имелся ввиду не макрос метод в каждом обработчике, а нечто одно на всю аксапту. Макрос который живет в AOT, статический метод, ф-ия в Global

[sukhanchik]

Цитата:

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

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

Забил ногами Даже возражать не собираюсь. Сдаюсь

[lev]

Цитата:

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

в замену одного числа в макросе/методе который это 255 определяет. Да и вероятность расширения енумов мала микроскопически

Дополнение. Имелся ввиду не макрос метод в каждом обработчике, а нечто одно на всю аксапту. Макрос который живет в AOT, статический метод, ф-ия в Global

Все равно мне кажется сомнительное решение. Использование констант в X++ не приветствуется.
На мой взгляд лучше подумать при создании enuma как он будет использоваться, в каких случаях по нему будут выполняться сравнительные действия, и уже продумать использовать в нем нулевой элемент, или нет.

Итого: на мой взгляд в Enum-параметрах лучше не использовать нулевой элемент.