JSF неявная и явная навигация

Я рассматривал использование явных правил навигации по страницам в своем веб-приложении, когда я пришел через этот вопрос/ответ SO, со следующим отрывом из него:

... правила навигации устарели, поскольку JSF 2.0 благодаря новой функции "неявной навигации".

Однако я прошел большую часть учебника CoreServlets JSF 2.0, и в нем есть раздел, посвященный явной навигации по страницам, и он говорит об этом благосклонно. Либо это идет вразрез с вышеупомянутой рекомендацией, либо я неправильно истолковываю что-то.

Я не хочу создавать новое веб-приложение устаревшим способом. Может ли кто-нибудь пролить свет?

Ответ 1

Это несколько субъективно, но ala, это сводится к следующему:

Правила навигации в XML - это адский аспект.
Использование правил навигации предполагает, что рассматриваемое веб-приложение страдает от проблемы "одного URL-адреса", которая вызывает плохой пользовательский интерфейс (страницы не являются заклассифицированными).
Использование правил навигации предполагает, что рассматриваемое веб-приложение использует POST для навигации по страницам, что приводит не только к плохому пользователю (страницы не являются заклассифицированными), но и плохой SEO (боты не индексируют POST, поэтому POST-навигационные страницы недоступны для общедоступных поисковых систем).

См. также:

Ответ 2

С чисто технической точки зрения правила навигации не устарели, поскольку ни спецификация, ни какой-либо API не отмечают их как устаревшие, устаревшие или кандидат, подлежащий обрезке.

Фактически, они получили некоторое оживление в JSF 2.2 с функцией Faces Flow для повторно используемых модулей.

Это на практике и, конечно же, когда функция Faces Flow не используется, я никогда не видел многого для правил навигации в XML. Они теоретически упростили бы техническое обслуживание (IIRC - одна из их первоначальных целей дизайна), но на практике, как BalusC упоминает, что это только вызывает адский ад.

Но, как сказал BalusC, это субъективно. Некоторым людям по-прежнему нравится сначала определять управляемые beans, инъекции (проводки), сопоставления объектов и то, что у вас есть в XML вместо аннотаций (и с XML только по возможности переопределить или для глобальных вещей).

На мой взгляд, правила навигации в основном отражают первоначальную попытку JSF слишком сильно абстрагироваться от HTTP и представить модель программирования на уровне более высокого уровня. В этой модели перенаправление на URL с параметрами запроса и у всех на самом деле не было места. В течение некоторого времени (начиная с JSF 2.0) JSF переместилась в более среднюю наземную модель, где простые запросы GET и PRG (Post-Redirect-GET) гораздо более восприняты. Следуя этой новой модели, вы действительно можете сказать, что правилам навигации нет места, то есть фактически устарели.

Ответ 3

Вы также можете использовать.

Явное средство в коде xml, которое приводит к:

Дополнительные накладные расходы, особенно если условия сложны (вы должны соответствовать результату метода действия с ожидаемыми значениями).

1b) Если есть опечатки, неявная навигация, вероятно, приведет к 404. Явное приведет к неправильной странице.
Вы можете использовать инструменты для рисования правил в графическом интерфейсе, которые затем генерируют faces-config.xml.
В последнее время изменение правил означает изменение XML (вам не нужно перекомпилировать). Если вы измените имена страниц URL/JSF, вам не нужно будет перекомпилировать.

Я бы сказал, что использование одного или другого - это вопрос предпочтения, я вполне доволен использованием скрытой навигации.