JSF-страница вперед в Tomee 7 [дубликат]

Самое простое решение - создать функцию JavaScript и вызвать его для обратного вызова Ajax success.

function callServerAsync(){
    $.ajax({
        url: '...',
        success: function(response) {

            successCallback(response);
        }
    });
}

function successCallback(responseObj){
    // Do something like read the response and show data
    alert(JSON.stringify(responseObj)); // Only applicable to JSON response
}

function foo(callback) {

    $.ajax({
        url: '...',
        success: function(response) {
           return callback(null, response);
        }
    });
}

var result = foo(function(err, result){
          if (!err)
           console.log(result);    
}); 
44
задан BalusC 30 January 2015 в 10:08
поделиться

1 ответ

Действительно, JSF как платформа, ориентированная на форму, ориентированная на MVC, передает форму POST на тот же URL-адрес, где запрашивается страница с <h:form>. Вы можете подтвердить это, посмотрев URL <form action> сгенерированного вывода HTML. Это в терминах веб-разработки, охарактеризованных как postback . Навигация по обратной передаче по умолчанию не вызывает новый запрос к новому URL-адресу, но вместо этого загружает целевую страницу в качестве содержимого ответа. Это действительно сбивает с толку, когда вы просто хотите навигация по страницам.

Как правило, правильный подход к навигации / перенаправлению зависит от бизнес-требований и idempotence (читайте: «bookmarkability») запроса.

  • Если запрос является идемпотентным, просто используйте форму / ссылку GET вместо формы POST (т. е. вместо этого используйте <form>, <h:link> или <h:button> из <h:form> и <h:commandXxx>). Например, навигация по страницам, формам поиска в Google и т. Д.
  • Если запрос не является идемпотентным, просто покажите результаты в одном представлении (т. Е. Return null или void и использовать, например, <h:message(s)> и / или rendered). Например, ввод / редактирование данных, многошаговый мастер, модальный диалог, форма подтверждения и т. Д.
  • Если запрос не является идемпотентным, но целевая страница является идемпотентной, просто отправьте перенаправление после POST ( т.е. вернуть результат с помощью ?faces-redirect=true или <redirect/>). Например, показывая список всех данных после успешного редактирования, перенаправляя после входа в систему и т. Д.

Обратите внимание, что чистая навигация по страницам обычно является идемпотентной, и именно здесь многие неудачники JSF терпят неудачу злоупотребляя командами / кнопками для этого, а затем жаловаться после этого, что URL-адреса не изменяются. Также обратите внимание, что навигационные случаи очень редко используются в приложениях реального мира, которые разрабатываются в отношении SEO / UX, и это приводит к тому, что многие учебники JSF терпят неудачу, позволяя читателям поверить иначе.

Также обратите внимание, что использование POST абсолютно не «более безопасно», чем GET, поскольку параметры запроса не отображаются сразу в URL-адресе. Они все еще видны в теле запроса HTTP и все еще манипулируются. Поэтому нет абсолютно никаких оснований предпочитать POST для идемпотентных запросов ради «безопасности». Реальная безопасность заключается в использовании HTTPS вместо HTTP и проверке методов бизнес-обслуживания, если в настоящее время зарегистрированный пользователь может запрашивать объект X или манипулировать объектом X и т. Д. Применимая система безопасности предлагает аннотации для этого.

См. также:

65
ответ дан Community 25 August 2018 в 19:01
поделиться
Другие вопросы по тегам:

Похожие вопросы: