Quelle est la différence, vraiment, entre les filtres et les intercepteurs? Je me rends compte que les intercepteurs se déclenchent avant et après une action, de manière récursive, et que les filtres peuvent être configurés pour se déclencher sur des actions et sur certains modèles d'URL. Mais comment savez-vous quand utiliser chacun?
Dans le livre que je lis sur Struts 2, il semble que des intercepteurs soient poussés et j'ai même suivi un tutoriel pour écrire un authentificateur Interceptor afin de s'assurer qu'un utilisateur est connecté. Cependant, si l'utilisateur tente d'accéder à une URL qui ne N'y a pas d'action associée, l'intercepteur ne l'attrape pas, ce qui signifie que je devrais associer une action à chaque jsp que je veux sécuriser. Cela ne semble pas juste.
Je peux créer un filtre d'authentification qui gère les URL afin de ne pas avoir à le faire, mais quel est l'intérêt des intercepteurs?
La différence la plus significative est que les "intercepteurs" font partie du framework Struts 2 et ne constituent qu’une partie du traitement de la demande effectué par le framework Struts 2. Les "filtres", d’autre part, font partie de la spécification Servlet; en d'autres termes, ils font partie de l'API Servlet. Si vous utilisez Struts 2, vous devez utiliser des intercepteurs pour envelopper les fonctionnalités autour de vos actions Struts 2. Si vous essayez de regrouper les fonctionnalités autour des demandes arrivant sur votre application Web, mais que Struts 2 ne les gère pas, un filtre est peut-être plus approprié.
En passant, l'ensemble de la structure Struts 2 est déployé à l'intérieur d'un filtre configuré dans votre application Web et déclaré dans le descripteur de déploiement de votre application Web (web.xml), comme suit:
<filter>
<filter-name>struts2</filter-name>
<filter-class>org.Apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Ce filtre, configuré pour intercepter tous les modèles d'URL de demandes, constitue le point d'entrée dans l'ensemble de la structure Struts 2.
J'espère que ça aide.
Qu'est-ce que l'intercepteur?
Struts 2 Framework utilise le concept d'intercepteur pour partager la solution à certaines préoccupations communes par différentes actions.
Comme nous le savons, le cadre appelle un objet Action particulier lors de la soumission d’une demande. Mais avant l'exécution de l'action, l'invocation est interceptée par un autre objet afin de fournir le traitement supplémentaire requis.
De même, après l'exécution de Action, l'invocation peut être interceptée à nouveau. Cet objet d'interception s'appelle Interceptor.
L'objectif d'Interceptor est donc de permettre un meilleur contrôle de la couche de contrôleur et de séparer une logique commune s'appliquant à plusieurs actions.
Le framework Struts 2 a déjà fourni son propre jeu d'intercepteurs pouvant être utilisés dans l'application pour fournir le traitement requis avant et après l'exécution des classes Action.
Un de ceux-ci est "Alias Interceptor" que je vais discuter ici.
Alias Interceptor:
Alias Interceptor est utilisé en cas de chaînage d'actions. Le chaînage des actions signifie qu'une action appelle une autre action après l'exécution réussie de la première action.
Cet intercepteur alias un paramètre nommé avec un nom de paramètre différent. Dans le chaînage d'actions, lorsque deux classes d'actions différentes partagent un paramètre commun portant un nom différent, cet intercepteur est utilisé pour attribuer un nom d'alias à un paramètre de la première classe d'action, qui correspond au nom du paramètre de la deuxième classe d'action.
Le pseudonyme d'expression d'action doit être sous la forme de:
#{ 'name1' : 'alias1' , 'name2' : 'alias2' }
la pile d'intercepteurs se déclenche à chaque requête.
Les filtres ne s'appliquent qu'aux URL pour lesquelles ils ont été définis.
modifier - vous utilisez l’un ou l’autre en fonction des besoins. Disons que vous devez vérifier qu'un cookie est présent pour chaque demande. Utilisateur un intercepteur. Disons que vous devez faire apparaître une application externe pour certaines demandes (pilotée par une URL), utilisez un filtre.
Je pense que les intercepteurs sont l'outil le plus couramment utilisé ...
pourquoi voudriez-vous une url sans action associée?
Conformément au cycle de vie/architecture des struts 2, aucun intercepteur n'est exécuté avant le filtrage. Donc, s'il n'y a pas de mappage d'action pour votre demande, il échoue lors du passage du filtre.
En règle générale
request
. La struts
elle-même est un filtre.interceptors
peut s'exécuter avant, après les actions struts. Ils ne s'exécuteront pas si la demande ne se termine pas par .action
. Ainsi, voici quelques exemples de filtres:
js
et css
, vous devriez opter pour des filtres et non des intercepteurs. chain.doFilter(request, response)
. Théoriquement, vous pouvez développer une application Web Struts sans développer votre propre variable interceptors
et utiliser filters
only. Mais vous devrez faire face à de nombreux problèmes et coder les filtres de chaudière.
Struts-default.xml ( https://struts.Apache.org/docs/struts-defaultxml.html ) permet de trouver quand. des intercepteurs peuvent être utilisés. (Par exemple, ParametersInterceptor
exécute before actions pour appliquer les valeurs de formulaire soumises aux actions)
Lorsque vous travaillez avec des intercepteurs, vous pouvez facilement accéder aux fonctionnalités de struts, par exemple getText
à partir de ressources de message, obtenir le nom de l'action en cours et l'espace de noms, modifier le flux d'actions.
Considérant ci-dessus, voici quelques cas pouvant être développés par des intercepteurs:
invocation.invoke()
Les intercepteurs fournissent le filtre et le modèle de conception de la chaîne de responsabilité pour les actions struts, tandis que les filtres fournissent ce modèle à l'ensemble de votre application Web.
Struts 2 Framework ne dépend pas de l'API Servlet. Struts 2 Les actions ne sont pas couplées à un conteneur. Le plus souvent, les contextes de servlet sont représentés sous forme de simples cartes, permettant de tester les actions de manière isolée.
Le filtre fait partie de l'API Servlet. Struts 2 Framework utilise donc le concept d'intercepteur pour partager la solution à certaines préoccupations communes par différentes actions.
Vous pouvez également écrire facilement des scénarios de test pour Interceptor et la classe Action.