Если вы не используете ajax или все еще используете JSF 1.x, и вам действительно нужно вызвать бизнес-действие в методе cancel()
(т. е. просто перезагрузить страницу недостаточно), тогда ваш лучший выбор для добавления immediate="true"
к кнопке. Таким образом, все поля ввода, которые не имеют immediate="true"
, будут пропускаться при обработке.
В JSF 2.x гораздо лучше отправить форму на
, которая по умолчанию только процессы @this
вместо @form
.
Если вы хотите перейти на другую страницу здесь, добавьте ?faces-redirect=true
к результату в методе cancel()
.
Или, если вам вообще не нужно вообще вызывать какие-либо бизнес-действия, просто используйте
, в котором вы прямо указываете результат (неявный) результат навигации.
Это будет в основном перезагрузите страницу запросом GET.
не существует в JSF 1.x, но вы также можете просто использовать для этого простой HTML + JS.
Хотя MINA и Netty имеют схожие амбиции, на практике они сильно различаются, и вам следует тщательно обдумать свой выбор. Нам повезло: у нас был большой опыт работы с MINA и у нас было время поиграть с Нетти.Нам особенно понравился более чистый API и гораздо лучшая документация. На бумаге производительность тоже казалась лучше. Что еще более важно, мы знали, что Trustin Lee будет готов ответить на любые наши вопросы, и он, безусловно, сделал это.
В Netty все стало проще. Период. Пока мы пытались реализовать ту же функциональность, что и в MINA, мы сделали это с нуля. Следуя превосходной документации и примерам, мы получили больше функциональности при гораздо меньшем количестве кода.
Netty Pipeline работал у нас лучше. Это как-то проще, чем MINA, где все является обработчиком, и вам решать, обрабатывать ли восходящие события, нисходящие события и то и другое или потреблять больше низкоуровневого материала. Жирать байты в «воспроизводящих» декодерах было почти приятно. Также было очень приятно иметь возможность так легко перенастроить конвейер на лету.
Но главная привлекательность Netty, imho, - это способность создавать обработчики конвейеров с «охватом одного». Вы, наверное, уже читали об этой аннотации покрытия в документации, но по сути она дает вам состояние в одной строке кода. Без возни, без карт сеансов, синхронизации и тому подобного, мы просто смогли объявить обычные переменные (скажем, «имя пользователя») и использовать их.
Но тут мы наткнулись на контрольно-пропускной пункт. У нас уже был многопротокольный сервер под MINA, в котором наш протокол приложения работал через TCP / IP, HTTP и UDP. Когда мы перешли на Netty, мы добавили в список SSL и HTTPS за считанные минуты! Пока все хорошо, но когда дело дошло до UDP, мы поняли, что ошиблись.MINA нам очень понравилась тем, что мы могли рассматривать UDP как «связанный» протокол. В Netty такой абстракции нет. Протокол UDP не требует установления соединения, и Netty рассматривает его как таковой. Netty раскрывает больше возможностей UDP без установления соединения на более низком уровне, чем MINA. Есть вещи, которые вы можете делать с UDP в Netty, чем вы не можете делать в абстракции более высокого уровня, которую предоставляет MINA, но на которую мы полагались.
Не так-то просто добавить оболочку "подключенного UDP" или что-то в этом роде. Учитывая нехватку времени и совет Trustin о том, что лучший способ продолжить - внедрить нашего собственного транспортного провайдера в Netty, что не будет быстрым, нам в конце концов пришлось отказаться от Netty.
Итак, внимательно посмотрите на различия между ними и быстро перейдите к этапу, на котором вы можете протестировать любую сложную функциональность, работающую должным образом. Если вы удовлетворены тем, что Нетти выполнит эту работу, я без колебаний согласен с ней, а не на MINA. Если вы переходите с MINA на Netty, то применимо то же самое, но стоит отметить, что эти два API действительно значительно отличаются, и вам следует подумать о виртуальном переписывании для Netty - вы не пожалеете об этом!
На сайте Netty вы можете найти некоторые отчеты о производительности . Как и ожидалось :-) они указывают на Netty как на фреймворк с лучшей производительностью.
Я никогда не использовал Netty, но я уже использовал MINA для реализации протокола TCP. Реализация кодирования и декодирования была простой, но реализация конечного автомата оказалась не такой простой. MINA предоставляет несколько классов, которые помогут вам при реализации конечного автомата, но я обнаружил, что их довольно сложно использовать. В конце концов мы решили отказаться от MINA и реализовать протокол с нуля, и, к удивлению, у нас получился более быстрый сервер.
Я использовал MINA только для создания небольшого http-сервера. Самые большие проблемы, с которыми я столкнулся до сих пор:
Приятные моменты:
MINA и Netty изначально были разработаны и созданы одним и тем же автором. Вот почему они так похожи друг на друга. MINA разработана на несколько более высоком уровне с немного большим количеством функций, в то время как Netty немного быстрее. Думаю, особой разницы нет, базовые концепции те же.
MINA обладает большим количеством внештатных функций за счет своей сложности и относительно низкой производительности. Некоторые из этих функций были интегрированы в ядро слишком плотно, чтобы их можно было удалить, даже если они не нужны пользователю. В Netty я попытался решить такие проблемы дизайна, сохранив при этом известные сильные стороны MINA.
В настоящее время большинство функций, доступных в MINA, также доступны в Netty. На мой взгляд, Netty имеет более чистый и документированный API, так как Netty является результатом попыток перестроить MINA с нуля и решить известные проблемы. Если вы обнаружили, что какая-то существенная функция отсутствует, пожалуйста, не стесняйтесь, напишите ваше предложение на форуме. Я буду рад ответить на ваши вопросы.
Также важно отметить, что Netty имеет более быстрый цикл разработки. Просто ознакомьтесь с датой выхода последних релизов. Также следует учитывать, что команда MINA перейдет на мажорную перепись, MINA 3, что означает, что они полностью нарушат совместимость с API.