Самое простое решение - создать функцию 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);
});
Действительно, JSF как платформа, ориентированная на форму, ориентированная на MVC, передает форму POST на тот же URL-адрес, где запрашивается страница с <h:form>
. Вы можете подтвердить это, посмотрев URL <form action>
сгенерированного вывода HTML. Это в терминах веб-разработки, охарактеризованных как postback . Навигация по обратной передаче по умолчанию не вызывает новый запрос к новому URL-адресу, но вместо этого загружает целевую страницу в качестве содержимого ответа. Это действительно сбивает с толку, когда вы просто хотите навигация по страницам.
Как правило, правильный подход к навигации / перенаправлению зависит от бизнес-требований и idempotence (читайте: «bookmarkability») запроса.
<form>
, <h:link>
или <h:button>
из <h:form>
и <h:commandXxx>
). Например, навигация по страницам, формам поиска в Google и т. Д. null
или void
и использовать, например, <h:message(s)>
и / или rendered
). Например, ввод / редактирование данных, многошаговый мастер, модальный диалог, форма подтверждения и т. Д. ?faces-redirect=true
или <redirect/>
). Например, показывая список всех данных после успешного редактирования, перенаправляя после входа в систему и т. Д. Обратите внимание, что чистая навигация по страницам обычно является идемпотентной, и именно здесь многие неудачники JSF терпят неудачу злоупотребляя командами / кнопками для этого, а затем жаловаться после этого, что URL-адреса не изменяются. Также обратите внимание, что навигационные случаи очень редко используются в приложениях реального мира, которые разрабатываются в отношении SEO / UX, и это приводит к тому, что многие учебники JSF терпят неудачу, позволяя читателям поверить иначе.
Также обратите внимание, что использование POST абсолютно не «более безопасно», чем GET, поскольку параметры запроса не отображаются сразу в URL-адресе. Они все еще видны в теле запроса HTTP и все еще манипулируются. Поэтому нет абсолютно никаких оснований предпочитать POST для идемпотентных запросов ради «безопасности». Реальная безопасность заключается в использовании HTTPS вместо HTTP и проверке методов бизнес-обслуживания, если в настоящее время зарегистрированный пользователь может запрашивать объект X или манипулировать объектом X и т. Д. Применимая система безопасности предлагает аннотации для этого.