Открытие форм с сервера с использованием MenuFunction

[gl00mie]

Не так давно потребовалось из класса, отрабатывающего на сервере, запускать форму, отображающую некоторые результаты его работы. Для формы есть пункт меню, запускающий ее на клиенте. Оказалось, что решение "в лоб" вовсе не обязательно приведет к желаемому эффекту:

MenuFunction menuFunc = new MenuFunction( menuitemdisplaystr(SomeForm), MenuItemType::Display );
Args         args     = new Args();
// ...
menuFunc.run( args );

Несмотря на то, что, опять же, в пункте меню явно прописано запускать форму на клиенте, никакого видимого эффекта в результате выполнения этого кода не наблюдалось. Опытным путем было выяснено, что для 3-ки и MenuFunction, и Args должны создаваться на клиенте, иначе форма не откроется. Для 4-ки вроде бы MenuFunction отрабатывает и с сервера, но в любом случае объект Args должен создаваться на клиенте - иначе клиент вообще сваливается. Для 3-ки дополнительные неудобства еще создает то, что конструктор MenuFunction требует передачи параметров, так что через какой-нить classFactory соотв. объект на нужном уровне не создашь; пришлось создавать через infolog:

MenuFunction menuFunc = infolog.getNode( UtilElementType::DisplayTool, menuitemdisplaystr(SomeForm) );
Args         args     = classFactory::makeObjectOnClient( classnum(Args) );
// ...
menuFunc.run( args );

Во вложении - небольшой проект для 4-ки с job'ом и пунктом меню для запуска его на сервере, демонстрирующий указанный эффект; в принципе, его можно и на 3-ке загрузить, только надо пункт меню для запуска job'а проверить и при необходимости подправить, чтобы запускался именно job, а не одноименная форма. В job'е в качестве тестовой формы открывается AddressTrans_RU через одноименный пункт меню, поскольку он - один из немногих, где для формы штатно прописано RunOn Client; обычно для форм в пунктах меню стандартного приложения прописано RunOn Called from.

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

PS. Axapta 3.0.1951.7669, также проверялось на AX 4.0.2501.116.

[kashperuk]

На самом деле - видимо что-то неправильно задизайнили, раз такое приходится делать.
Концептуально это неверно.
Хорошо конечно, что есть дыра, через которую получилось пролезть.. но ее могут и заткнуть. и что тогда?

[petergunn]

Цитата:

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

Не так давно потребовалось из класса, отрабатывающего на сервере, запускать форму, отображающую некоторые результаты его работы. Для формы есть пункт меню, запускающий ее на клиенте. Оказалось, что решение "в лоб" вовсе не обязательно приведет к желаемому эффекту:

MenuFunction menuFunc = new MenuFunction( menuitemdisplaystr(SomeForm), MenuItemType::Display );
Args         args     = new Args();
// ...
menuFunc.run( args );

А такой вариант запуска на клиенте не тестировали?

MenuFunction::runClient( menuitemdisplaystr(AddressTrans_RU), MenuItemType::Display ) ;

[gl00mie]

Цитата:

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

А такой вариант запуска на клиенте не тестировали?

MenuFunction::runClient( menuitemdisplaystr(AddressTrans_RU), MenuItemType::Display ) ;

На 3-ке тестировал - при выполнении кода с сервера эффект нулевой.

[gl00mie]

Цитата:

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

На самом деле - видимо что-то неправильно задизайнили, раз такое приходится делать. Концептуально это неверно.

Пардон, кто неправильно задизайнил, я или разработчики ядра Аксапты? Я всегда был убежден, что свойство RunOn пункта меню четко и однозначно характеризует намерения разработчика (если, конечно, оно не конфликтует с соотв. свойством класса, но речь сейчас не о классах), и MenuFunction'у должно быть безразлично, где он сам создан, если в пункте меню указано, где создавать связанный объект.
Собственно, что такого неправильного в том, как у меня "задизайнено"? Есть форма, отображающая строчки из определенной таблицы, есть класс, который дергается из другой формы, крутится на сервере, создавая записи в этой таблице, и затем по результатам работы открывает форму для отображения созданных записей - или не открывает, если что-то пошло не так и записи не создались. Я исхожу из того, что:

• Форма отображения не обязана знать о существовании этого класса - это не ее забота, достаточно того, что он передает ей аргументы в том виде, какой она понимает;
• Класс не обязан выполняться на клиенте ради обхода каких-то гхм... особенностей работы MenuFunction;
• Создавать статический клиентский метод моего класса или, там, класса Global только ради того, чтобы создать MenuFunction на клиенте, тоже совершенно неинтересно.

Цитата:

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

Хорошо конечно, что есть дыра, через которую получилось пролезть.. но ее могут и заткнуть. и что тогда?

К тому времени, я очень надеюсь, разработчики ядра исправят этот косяк, и "лезть через дыры" уже не придется. Фиг бы с ним, с MenuFunction - вот почему из-за Args, созданного на сервере, при открытии формы на клиенте Аксапта валится?.. И ведь нигде в документации вроде не упоминается, что передаваемый экземпляр Args должен быть создан именно на клиенте.

[kashperuk]

Под "неправильным" дизайном я подразумевал вот что:
АОС - один (утрирую) на много клиентов.
Код, выполняющийся на сервере, знает, конечно, в каком конкретно процессе он выполняется и т.д. и т.п., поэтому можно сделать вызов чего-то на клиенте.
Но правильно ли это?

Думаю, что лучше было бы, если бы клиент вытягивал результаты работы с сервера (pull method).
Хотя, это мое личное мнение, возможно многие с ним не согласны.

А про Args - я проверю.

[plumbum]

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

Я не знаю конечно вашу задачу, но в этом случае все обычно корректно отрабатывает...