Как использовать xe:jsonRpcService?

Question

Я пытаюсь использовать компонент библиотеки расширений Remote Service (xe:jsonRpcService). Я получил несколько подсказок здесь и здесь. В основном я пытаюсь сохранить документ с помощью RPC. Проблема в том, что документ сохраняется, но он не сохраняет поля, присутствующие в XPage. Ниже приведен пример кода XPage:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core" xmlns:xe="http://www.ibm.com/xsp/coreex">
    <xp:this.data>
        <xp:dominoDocument var="document1" formName="Test"></xp:dominoDocument>
    </xp:this.data>
    <xe:jsonRpcService id="jsonRpcService1" serviceName="service">
        <xe:this.methods>
            <xe:remoteMethod name="saveDoc">
                <xe:this.script><![CDATA[print(">> " + getComponent("inputText1").getValue());
document1.save();
return true;]]></xe:this.script>
            </xe:remoteMethod>
        </xe:this.methods>
    </xe:jsonRpcService>
    <xp:br></xp:br>
    <xp:inputText id="inputText1" defaultValue="testValue" value="#{document1.testField}"></xp:inputText>
    <xp:br></xp:br>
    <xp:button value="Save" id="button1">
        <xp:eventHandler event="onclick" submit="false">
            <xp:this.script><![CDATA[var deferred = service.saveDoc();
deferred.addCallback(
    function(result) {
        alert(result);
    }
);]]></xp:this.script>
        </xp:eventHandler>
    </xp:button>
</xp:view>

Что я сделал здесь, так это то, что я создал Remote Service (service) где я сохраняю текущий документ (document1). Сохраняет документ, но не сохраняет значение в inputText1, Кроме того, когда я пытаюсь напечатать значение inputText1 он отображается на консоли, но не сохраняется.

Это правильный способ сделать это? Или я что-то здесь упускаю. Также, что было бы несколько сценариев, где использование xe:jsonRpcService будет оправданным?

Answer 1

Есть (как минимум) две причины, по которым следует избегать использования JSON-RPC для этого типа операций:

1. Этот сервисный компонент разработан как можно более легким, поэтому, в отличие от стандартных событий в XPages (которые автоматически публикуют всю HTML-форму), он отправляет только данные, необходимые для вызова метода, и получает только данные, возвращенные методом. В вашем примере метод не принимает аргументов, поэтому он буквально просто посылает достаточно информации, чтобы сервер знал, какой метод вызывать; аналогично, вы просто возвращаете логическое значение, так что это буквально все, что будет отправлено обратно. Если вы используете инструменты разработки вашего браузера (например, Firebug или встроенные инструменты в Chrome) для проверки сетевого трафика, вы увидите это в пакетах JSON, которые отправляются в каждом направлении. В результате сервер не "знает" ничего, что вы явно не "говорите" ему. Так что это быстрее, чем обычное событие, потому что вы не публикуете ничего, что не имеет явного отношения к вызываемому методу... но вы должны преднамеренно отправлять все, что нужно методу для запуска.
2. Еще одним побочным эффектом концентрации компонента на производительности является то, что он пропускает сериализацию дерева компонентов в конце жизненного цикла JSF. Если вы сохраняете текущую страницу в памяти, это не должно вызывать проблем, но если вы используете опцию по умолчанию (сохранить все страницы на диске), сервер "забудет" обо всех изменениях, внесенных в страницу. во время вызова метода. Вы можете явно переопределить это поведение в каждом конкретном случае, напрямую сказав корню представления, чтобы сериализовать его состояние, но легко забыть, что вы должны делать это вручную, что обычно вызывает большое разочарование, когда вы видите сервер индикации -то, что он делает то, что должен, но реальная веб-страница не отражает это. Лучше всего просто рассматривать любой метод RPC как операцию "только для чтения", если вы не уверены, что всегда будете помнить этот странный побочный эффект и понимать, как его обойти.

Мой совет - думать о JSON-RPC как о "SOAP минус глупый". Говоря более вежливо, он концептуально идентичен веб-службам, но не имеет всей сложности веб-служб. Как таковые, эти типы сервисов идеальны для операций с данными, которые полезны в контексте текущей страницы без явной привязки к состоянию текущей страницы.

Вот несколько примеров операций, в которых может быть полезен метод JSON-RPC:

• Информирование нового пользователя о том, что имя пользователя, которое он выбирает для своей новой учетной записи, уже занято. Вместо того, чтобы связывать стандартное событие keyup, которое будет отправлять всю форму, отправлять только значение одного поля в службу, запрашивать его в записях регистрации сайта и возвращать логическое значение.
• Живой опрос связанных данных, которые подвержены частым обновлениям. Предположим, вы разрабатываете CRM и хотите отобразить цену акций компании, чей аккаунт вы просматриваете. Использование setInterval для периодического запроса у RPC обновленной цены акций, а затем ручное манипулирование DOM на стороне клиента в случае изменения цены снова позволяет выполнить несколько сложную операцию с минимальными затратами сети.

Это не означает, что вы не можете использовать RPC для операций записи... но для любой операции, которая нуждается в полном, актуальном контексте (то есть текущем значении каждого поля на текущей странице) для правильной работы, стандартный обработчик событий почти всегда лучший подход.