2009-02-19 11 views
1

Je suis tout à fait nouveau pour ICEfaces mais ont déjà une expérience avec JSF/Facelets et Java EE en général.ICEfaces: comment désactiver le mécanisme d'émission-réception-mises à jour pour certaines formes

Actuellement, je ne suis pas en utilisant une grande partie de ICEfaces, sauf quelques balises utilitaires comme outputStyle et outputDeclaration, mais même cela est vraiment agréable d'avoir.

Même si je prévois d'utiliser des fonctionnalités AJAX plus tard, j'ai des formulaires h: forms (ou ice: forms) que je voudrais envoyer en tant que requêtes JSF POST normales, sans passer par/block/send-receive-updates . La raison en est que je veux utiliser un filtre, qui agit sur l'URI demandé, ce qui est impossible si tout est envoyé à/block/send-receive-updates.

Existe-t-il un moyen de le faire?

Edit: Pour clarifier ce que je veux faire:

Le site web nous développons se compose de pages accessibles au public et certains qui ne peuvent accéder qu'aux membres enregistrés. Le mécanisme de sécurité basé sur FORM standard tel que défini dans la norme de servlet est assez rigide, car il ne permet que de définir une seule page de connexion qui est affichée, quand quelqu'un veut accéder à un contenu restreint. Parce que nous voulons aussi pouvoir nous connecter en utilisant un petit formulaire de connexion visible sur chaque page, nous avons développé un filtre, qui gère l'authentification et l'autorisation presque comme le conteneur web. Il redirige vers une page de connexion personnalisée si l'utilisateur n'est pas authentifié/autorisé, mais permet également d'authentifier un utilisateur à partir d'un backing-bean. Pour que cela fonctionne presque de manière transparente, il enveloppe le HttpServletRequest pour fournir les rôles Principal et Utilisateur.

Lorsque le filtre redirige vers la page de connexion personnalisée enregistre il la demande en cours de « rejouer » plus tard, lorsque l'utilisateur a été authentifié avec succès. Pour ce faire, le filtre doit être capable de détecter si une requête POST provient de la page de connexion (et donc si l'utilisateur est maintenant authentifié/autorisé). Mais si chaque POST passe par/block/send-receive-updates cela ne marche plus.

Bien sûr, je pouvais exclure la gestion de la page de connexion par ICEfaces, mais cela signifiait que je ne pouvais utiliser aucun ICEfaces/AJAX sur la page de connexion.

Répondre

1

Cette méthode n'est peut-être pas la meilleure, mais elle peut être de façon. Je suppose, pour les besoins de l'argument, que votre en-tête contient votre formulaire de connexion supplémentaire. Si vous deviez créer votre en-tête dans un cadre séparé ou dans la page de disposition principale et insérer vos pages JSF dans un iframe, cela pourrait fonctionner. L'idée étant que, étant donné qu'il est rendu en tant que page séparée, vous pouvez le gérer de manière séparée.

En outre, il pourrait y avoir une autre façon de gérer votre sécurité qui rendrait cela plus Icefaces-y.Peut-être, quand vous frappez le filtre et qu'il détermine que vous n'êtes pas connecté, il devrait créer un bean (probablement session) qui contient les informations de la demande d'origine (URL, paramètres, etc.) et vous envoie sur le page de connexion. La page de connexion fait sa chose, ajoute vos trucs de sécurité, puis utilise les informations dans ce bean de session pour forcer une redirection vers votre nouvelle page. Vous pouvez utiliser le FacesContext pour obtenir votre HttpContext et faire une redirection. Vous auriez probablement besoin de jouer avec la redirection pour ajouter des paramètres appropriés. Enfin, vous devriez vous débarrasser du bean session.

Enfin, je sais qu'il ya deux ou trois cadres (printemps WebFlow, ressorts à l'esprit) qui sauvera votre état de demande, vous permet de faire le login, et vous rediriger à l'endroit où vous allez dans la première endroit assez transparente (qui, me rappelle, je pense que Seam peut le faire aussi. Probablement orchestre et vos autres cadres aussi bien.)

Hope this helps!

+0

Merci pour les idées. Ce qui me dérange vraiment de tout cela est que je pensais au départ ICEfaces était plus d'une bibliothèque de composants pour JSF comme RichFaces, mais maintenant il semble qu'il dicte tout à fait comment tout devrait fonctionner ... –

+1

Ouais, ICE-Faces est plus juste une bibliothèque de composants et bien qu'il ne soit pas timide, il pourrait probablement faire un peu mieux d'en parler aux gens. En particulier, son rendu direct vers DOM signifie que vous utilisez un moteur de rendu complètement différent. Je suggérerais de mieux le connaître. – Drew

1

J'utilise Icefaces depuis près d'un an et n'ont pas encore rencontré aucune façon de soumettre le formulaire sans passer par émission-réception-mises à jour. Mais je suis curieux, vous dites "je prévois d'utiliser des fonctionnalités AJAX plus tard". Le but de IceFaces est d'ajouter de manière transparente AJAX à votre application JSF. C'est une sorte de «tout ou rien» - n'importe quelle page que vous utilisez qui utilise IceFaces utilisera AJAX. La seule chose que je peux penser de vous pourrait faire est de ne pas utiliser IceFaces pour les pages que vous voulez utiliser sur les requêtes POST, c'est-à-dire que vous pouvez mapper les pages IceFaces à * .iface, mais JSF normal aux * .faces.

Sinon, il pourrait bien y avoir un autre moyen d'accomplir ce que vous voulez faire avec les filtres.

+0

C'est probablement le "tout ou rien" qui rend impossible de faire ce que je veux. J'ai déjà regardé en utilisant RichFaces/AJAX4JSF qui semblent être plus flexibles. J'ai mis plus d'informations sur ce que je veux faire avec les filtres dans la question. –