Eclipse Scout Neon Message box, инициированный на стороне сервера

Question

Мне интересно, есть ли способ вызвать окно сообщения на стороне сервера.

Мое дело в том, что у меня есть логика на стороне сервера скаутского приложения. В середине процесса необходимо принять какое-то решение. В этом случае я хотел бы вызвать окно сообщения с параметрами YES, NO, CANCEL.

Как моя логика очень тяжело разбить ее на две функции и сначала позвонить первым, задать вопрос и позвонить другому с ответом. Так что это не для меня.

Если вы не можете вызвать окно сообщения в службе разведки, есть ли способ «имитировать» его. Поэтому вызовите метод обслуживания, в средней паузе он, перейдите на клиентскую сторону, представите поле messsage, вернитесь к тому же методу службы и продолжите его.

Зачем мне это нужно:

У меня есть зависимости графы (между полями), реализованным на стороне сервера разведчика. После того, как одно поле было изменено, весь граф зависимостей будет разрешен. Один узел графика имеет некоторую логику, которая требует взаимодействия с пользователем. Проблема в том, что я не знаю, будет ли этот метод вызываться (зависит от графика), и если после этого метода будут вызваны другие кивки.

Answer 1

Вы задали очень похожий вопрос несколько месяцев назад: Scout Eclipse present optional message on server side

MessageBox является концепция клиента (пакет: org.eclipse.scout.rt.client.ui.messagebox).

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

Answer 2

Как уже говорило Jmini, MessageBox - это концепция клиента. Что вы можете сделать, это отправить статус (от сервера к клиенту), проверить его на стороне клиента и показать соответствующее сообщение (поле). Но тогда вы прерываете свой метод обслуживания и не можете продолжать работу там, где он остановлен (альтернативно вы можете выбросить исключение VetoException, но это также прерывает ваш метод обслуживания, поэтому такая же проблема). На мой взгляд, также неплохой дизайн «запрашивает» взаимодействие пользователя со стороны сервера, поскольку в этом случае стороне сервера приходится ждать ответа пользователя.
Я предлагаю, если возможно, разделить вашу логику на разные части. Сначала вы выполняете первую часть, пока не достигнете точки, в которой вам нужно взаимодействие с пользователем. Затем вы можете сохранить текущее состояние выполнения, вернуться к клиенту и показать сообщение. После того, как пользователь ответил, вы должны запустить «второе» выполнение, в зависимости от ввода пользователя. Это второе исполнение должно быть запущено путем вызова другой (новой) службы, которая сначала должна загрузить или восстановить состояние выполнения, сохраненного до запроса пользователя.