1. Le client initialise une demande au conteneur servlet (TOMCAT);
2. Cette demande passe par une série de filtres, puis FilterDispatcher est appelé;
3. FilterDispatcher demande à ActionMapper de décider si la demande doit appeler une certaine action;
4. Si ActionMapper décide d'appeler une action, FilterDispatcher remet le traitement de la demande à ActionProxy. ActionPro demande le fichier de configuration de Framework en fonction du ConfigurationManager et trouve la classe d'action qui doit être appelée, en lisant généralement Strut.xml;
5. ActionProxy crée une instance d'actionInvocation. L'instance ActionInvocation est appelée à l'aide d'un modèle nommé. Avant et après le processus d'appel de l'action, l'appel de l'intercepteur pertinent est impliqué;
6. Une fois l'action exécutée, ActionInvocation trouve le résultat de retour correspondant en fonction de la configuration dans strut.xml.
Par exemple le code:
Après que Struts2 ait obtenu la demande .Action, elle décidera du composant logique métier à appeler en fonction du partiel;
Toutes les actions dans les applications Struts2 sont définies dans struts.xml;
L'instance d'action utilisée par Struts2 pour gérer les demandes de l'utilisateur n'est pas un contrôleur commercial implémenté par l'utilisateur, mais un proxy d'action, car le contrôleur de service implémenté par l'utilisateur n'est pas couplé avec le servletAPI et ne peut évidemment pas gérer les demandes de l'utilisateur.
<html> <éad- head> <ititle> Success </ title> </ head> <body> <form action = "hello.action" metheth = "Post"> username: <input type = "text" name = "name"> </br> mot de passe: <input type = "mot de passe" name = "pass"> </br> <entrée type = "souples" value = "soumission"> </ form> </body> </ html>
Par exemple, Hello.action du formulaire ci-dessus, cette propriété d'action n'est pas un servlet ordinaire ou une page JSP dynamique. Lorsque le formulaire est soumis à Hello.Action, le filterDispatcher de Struts2 fonctionnera et transmetra la demande de l'utilisateur à l'action correspondante.
Notez que Struts2 Action intercepte toutes les demandes avec des suffixes .Action par défaut. Si nous devons soumettre le formulaire à l'action pour le traitement, l'attribut d'action du formulaire doit être défini au format de .Action.
Classe de contrôleur
classe publique HelloAction {Nom de chaîne privée; Pass de chaîne privée; public void setName (nom de chaîne) {this.name = name;} public void setPass (String Pass) {this.pass = pass;} public String execute () {if ("yang" .equals (name) && "1234" .equals (pass)) {return "Success";} else {return "error";}};;Une fois l'exécution précédente terminée, le transfert de page n'est effectué que et l'état de l'utilisateur n'est pas suivi. Lorsque l'utilisateur se connecte, nous devons ajouter le nom d'utilisateur de l'utilisateur comme information d'état de la HTTPSession.
Afin d'accéder à l'instance httpSession, Struts2 fournit une classe ActionContext, qui fournit une méthode getSession (), mais la valeur de retour de cette méthode n'est pas httpSession () mais map (), mais l'intercepteur de Struts2 sera responsable de la commutation entre la session () et HttScession ().
Afin de vérifier si l'attribut de session que nous définissons est réussi, nous pouvons définir l'interface après le succès
<Html> <A-head> <base href = "<% = basepath%>" rel = "external nofollow"> <itle> Success </Title> </ head> <body> bienvenue, $ {Sessionscope.User}, vous êtes déjà connecté. </ body> </html>Utilisez la syntaxe d'expression JSP2.0 pour sortir l'attribut utilisateur dans la session HTTP.
Intégration de classe d'outils d'action ActionSupport
La classe ActionSupport est une classe d'outils et a implémenté l'interface d'action. De plus, il implémente également l'interface validateablez, fournissant une fonction de vérification des données.
Afin d'augmenter la fonction de vérification des données d'entrée, ajoutez la méthode de validation de réécriture en action.
public void validate () {if (getName () == null || getName (). Trim (). equals ("" ")) {addFielDerror (" name ", getText (" name.Required "));} if (getPass () == null || getPass ()"). getText ("Pass.Required"));}}La méthode Validate réécrite ajoutée ci-dessus sera exécutée avant la méthode EXECUTE () du système. Si le Fielderror de la classe d'action contient déjà des erreurs de vérification des données après avoir exécuté cette méthode, la demande sera transmise à la vue logique d'entrée, vous devez donc également ajouter le nom de vue logique d'entrée dans strut.xml pour le laisser passer à la page de connexion.
L'inconvénient de cette méthode valide est qu'il nécessite une grande réécriture de la méthode Validate, vous pouvez donc utiliser le cadre de vérification de Struts2.
<? xml version = "1.0" Encoding = "UTF-8"?> <! Doctype Validators public "- // Openymphony Group // XWork Validator 1.0.3 // en" "http://www.opensymphony.com/xwork/xwork-validat name = "name"> <field-validator type = "requirestString"> <message key = "name.requured" /> </ field-validator> </ field> <! - Vérifier le formulaire pass
Résumer
Ce qui précède est l'intégralité du contenu de cet article sur le processus de Struts2 et une série d'analyses de code de connaissances connexes. J'espère que ce sera utile à tout le monde. Les amis intéressés peuvent continuer à se référer à d'autres sujets connexes sur ce site. S'il y a des lacunes, veuillez laisser un message pour le signaler. Merci vos amis pour votre soutien pour ce site!