Comment naviguer dans JSF? Comment faire pour que L'URL reflète la page actuelle (et pas la précédente))

je suis en train d'apprendre JSF et j'étais plutôt étonné et perplexe quand j'ai réalisé que chaque fois que nous utilisons <h:form> , le comportement standard de JSF est de toujours me montrer L'URL de la page précédente dans le navigateur, par opposition à L'URL de la page actuelle .

je comprends que cela a à voir avec la façon dont JSF poste toujours un formulaire sur la même page et ensuite rend juste n'importe quelle page que le contrôleur lui rend pour le navigateur qui ne connaît pas l'emplacement de la page a changé.

il semble que JSF soit là depuis assez longtemps qu'il doit y avoir un moyen propre et solide pour faire face à cela. Si oui, auriez-vous l'esprit de partage?

j'ai trouvé diverses solutions de rechange, mais malheureusement rien qui semble être une véritable solution solide.

  • simplement accepter que L'URL est trompeuse.
  • annexe "?faces-redirect=true" à la valeur de retour de chaque action de bean et puis
    • trouvez comment remplacer @RequestScoped par autre chose (Flash Scopes, CDI conversation, @SessionScoped, ...).
    • accepte D'avoir deux aller-retour HTTP pour chaque action de l'utilisateur.
  • utilisez une méthode quelconque (par exemple une bibliothèque tierce partie ou un code personnalisé) pour cacher le nom de la page dans L'URL, toujours en utilisant le même générique URL pour chaque page.

si "?faces-redirect=true" est aussi bon qu'il obtient, y a-t-il un moyen de configurer une application entière pour traiter toutes les requêtes de cette façon?

44
demandé sur BalusC 0000-00-00 00:00:00

1 réponses

en effet, JSF comme étant une application basée sur un formulaire ciblé MVC framework soumet le formulaire de poste à la même URL que celle où la page avec le <h:form> est demandée. Vous pouvez le confirmer en regardant L'URL <form action> de la sortie HTML générée. Ceci est en termes de développement web caractérisé comme postback . Une navigation sur un postback ne provoque pas par défaut une nouvelle requête à la nouvelle URL, mais charge plutôt la page cible comme contenu de réponse. C'est en effet confus quand vous voulez simplement la navigation de page en page.

en règle générale, la bonne approche en matière de navigation/redirection dépend des exigences commerciales et de la idempotence (lire:" bookmarkability") de la demande.

  • si la requête est idempotent, il suffit d'utiliser un formulaire GET / lien au lieu du formulaire POST (i.e. utiliser <form> , <h:link> ou <h:button> à la place de <h:form> et <h:commandXxx> ).

    Par exemple, navigation de page en page, Formulaire de recherche de type Google, etc.

  • si la requête n'est pas idempotent, il suffit de montrer les résultats conditionnellement dans la même vue (i.e. retourner null ou void et utiliser par exemple <h:message(s)> et/ou rendered ).

    Par exemple, entrée/édition de données, Assistant multi-étapes, Dialogue modal, formulaire de confirmation, etc.

  • si la requête n'est pas idempotent, mais que la page cible est idempotent, il suffit d'envoyer une redirection après la publication (i.e. résultat de retour avec ?faces-redirect=true ou <redirect/> ).

    Par exemple, en montrant la liste de toutes les données après l'édition réussie, la redirection après la connexion, etc.

notez que la navigation de page à page pure est généralement idempotent et c'est là que de nombreux démarreurs JSF échouent par abuser des liens/boutons de commande pour cela et ensuite se plaindre que les URLs ne changent pas. Notez également que les cas de navigation sont très rarement utilisés dans les applications du monde réel qui sont développées en relation avec SEO/UX et c'est là que de nombreux tutoriels JSF échouent en laissant croire le contraire aux lecteurs.

notez également que L'utilisation de POST n'est absolument pas" plus sécurisée " que GET car les paramètres de la requête ne sont pas immédiatement visibles dans L'URL. Ils sont encore visibles dans HTTP demande corps et toujours manipulable. Il n'y a donc absolument aucune raison de préférer les requêtes POST for idempotent au nom de la "sécurité". La vraie sécurité est d'utiliser HTTPS au lieu de HTTP et de vérifier les méthodes de service aux entreprises si l'utilisateur actuellement connecté est autorisé à interroger l'entité X, ou à manipuler l'entité X, etc. Un décent

66
répondu