выделение / ошибка не работает для «удаленной» проверки - PullRequest
0 голосов
/ 29 октября 2018

Я использую с Bootstrap 4 и chargify, что потребовало небольшой настройки во время инициализации. Визуальные настройки и submitHandler, похоже, не являются проблемами. Тем не менее, я также использую «удаленный» параметр ( документация ), где моя проблема, кажется, кроется. Моя текущая инициализация такая:

// note: app.form is a cached jQuery object wrapping the form in question
app.form.validate({
    submitHandler: function (form) {
        if (form.valid()) {
            chargify.token(
              form,
              function success(token) {
                  document.querySelector('#chargifyToken').value = token;
                  form.submit();
              },
              function error(err) {
                  console.log('token ERROR - err: ', err);
              }
            );
        }
    },
    highlight: function (element) {
        $(element).addClass('is-invalid');
    },
    unhighlight: function (element) {
        $(element).removeClass('is-invalid');
    },
    errorClass: 'invalid-feedback',
    errorElement: 'div',
    rules: {
        "subDomain": {
            required: true,
            minlength: 2,
            remote: '../servlet/CheckSubDomainServlet'
        }
    }
});

Вся полнота инициализации приведена для полноты картины, но я не уверен, что она важна.

Проблема

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

Но когда "удаленный" URL-адрес наконец-то вызывается, поведение не соответствует ожидаемому. Независимо от того, пройден он или нет, поле остается выделенным ".is-invalid", что также скрывает обратную связь. Независимо от своего скрытого состояния, элемент ".invalid-feedback" также не заполняется сообщением.

Возвращаемый JSON поставляется в одном из двух форматов. Первый пример провал, второй проход:

{
  "subDomain":"SubDomain can't be only numeric"
}

или

{
  "subDomain":true
}

Теперь, документация НЕ БОЛЬШАЯ для удаленной опции, но я ДУМАЮ, что форма, которую должен принять возврат. Их собственные связанные примеры, кажется, показывают эту подпись.

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


UPDATE

Я полагаю, что на самом деле это ответ JSON, который все портит. Если я смотрю непосредственно на исходный код проверки, он хочет увидеть, если response == true || response || response == "true" для части правды. Что странно, потому что он также документирует это: «Ответ сервера должен быть строкой JSON, которая должна быть« истинной »для допустимых элементов и может быть« ложной », неопределенной или нулевой для недопустимых элементов».

Конечно, нет такой вещи, как строка JSON без ключа, с которым можно было бы ей соответствовать, и в документации не указано, каким должен быть ключ. Я экстраполировал, просматривая ответные сообщения с их образцами страниц. Так что теперь я не уверен, что ответ должен быть, или как их примеры страниц на самом деле работают успешно. Я чувствую, что это "сработало бы", если бы мой ответ был html / text в формате "true" или "Some message" без JSON вообще.

ОБНОВЛЕНИЕ 2: РЕШЕНИЕ

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

Ответ должен быть в приложении / тексте, и весь текст ответа должен содержать либо:

"true"

или

"Some custom error message"

С этим все готово. Оказывается, с документацией тоже все в порядке, но меня выбрасывает термин «строка в формате JSON», который на самом деле означает «завернутый в двойные кавычки и содержащий только допустимые символы». Я думал, что это означает, что нужен целый объект JSON.

1 Ответ

0 голосов
/ 30 октября 2018

Чтобы было легче найти, вот ответ, полученный из комментариев Спарки в оригинальном вопросе:

Ответ должен быть в приложении / тексте, и весь текст ответа должен содержать либо:

"true"

или

"Some custom error message"

Требуются двойные кавычки, и это не должен быть какой-либо законченный объект JSON. С этим все готово. Оказывается, с документацией тоже все в порядке, но меня выбрасывает термин «строка в формате JSON», который на самом деле означает «завернутый в двойные кавычки и содержащий только допустимые символы». Я думал, что это означает, что нужен целый объект JSON.

Наш Java-код в конечном итоге выполняет внутреннюю проверку и уже имеет доступ к классу HttpServletResponse. Затем он просто создает PrintWriter на основе HttpServletResponse.getWriter () и записывает в него:

PrintWriter out = null;

// ... later ...
// "response" was passed in as type HttpServletResponse
out = response.getWriter();

// out is just a buffer for what gets dumped into response body
out.println(resultingString);
out.flush();
out.close();
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...