Si la salle informatique est sur le point de fermer ou si vous avez hâte de sortir avec une fille, passez directement au quatrième paragraphe naturel.
Les scripts décrits ci-dessous incluent des scripts côté serveur et des scripts côté client. Les scripts côté serveur font référence à la partie du script qui s'exécute sur le serveur. Par exemple, le Response.Write commun est évidemment exécuté côté serveur. les scripts peuvent être écrits à l'aide des langages VBScript et JScript, VBScript et Jscript sont tous utilisés dans cet article.
Les scripts côté client peuvent également être considérés comme incluant deux langages : VBScript et JavaScript, qui sont des langages de script qui s'exécutent sur le navigateur client. Par exemple, lorsque nous visitons une page Web et qu'une boîte de message apparaît, cela se fait à l'aide de scripts côté client (alerte, msgbox, etc.), et ce n'est évidemment pas quelque chose que les scripts côté serveur peuvent faire. Il existe une autre grande différence entre les scripts côté client et les scripts côté serveur (dans les navigateurs tels que IE et Firefox), à savoir que les scripts côté client peuvent accéder au modèle d'objet de document (DOM) et manipuler des objets dans la page (tels que comme modifier le titre de la page, Modifier l'attribut innerHTML d'un div, etc.).
Tout d’abord, examinons le processus d’exécution des pages ASP.
1. IIS recherche le fichier ASP et le soumet au moteur ASP (généralement ASP.DLL) pour traitement.
2. Le moteur ouvre le fichier ASP et trouve le contenu entre <% et %>, et bien sûr le contenu entre <script runAt=server> et le </script> correspondant. Ces contenus sont appelés blocs de script. Seul le contenu du bloc de script est analysé par le moteur, et les autres contenus sont ignorés et insérés entre les blocs de script en tant que caractères dénués de sens. Il est nécessaire d'expliquer qu'en fait, le contenu analysé est bien plus que cela. Les fichiers include côté serveur de la classe <!--#include ***--> sont également inclus et traités par le moteur. Si vous lisez beaucoup de programmes, vous saurez également que certains objets <object> dont les attributs runAt sont marqués comme Server seront également traités. Nous n'en discuterons pas en profondeur ici.
3. Le moteur exécute les scripts du bloc de script. Ces scripts côté serveur sont exécutés dans leur ensemble, c'est-à-dire que le code suivant peut être écrit :
<%
Faible je
Pour i=1 à 5
%> Bonjour tout le monde !
<% Suivant %>
Le moteur n'analyse pas ces blocs de script séparément, ce qui entraîne des erreurs de syntaxe dans les deux blocs de script. Nous arrivons donc à la conclusion suivante : tout le code de script non-serveur ne sera pas envoyé au client. Il est possible que ce code de script non-serveur soit restreint par le bloc de script. Le serveur ne se souciera certainement pas de l'exécution des scripts clients, mais il peut générer différents scripts clients via des scripts côté serveur.
4. Enfin, le moteur génère un flux de texte, ou le résultat de l'exécution du script, qui peut être considéré comme une chaîne, qui est le code de la page web envoyé au navigateur client. Le navigateur client affiche la page A ce moment, le code source (fichier source) de la page ne contient pas le script côté serveur, mais contient le résultat de l'exécution du script côté serveur (c'est évident).
<% … %> et <script runat=server>…</script>
Ce sont tous des scripts côté serveur qui sont traités et exécutés en même temps. Ils fonctionnent comme une unité.
<% … %> et <script language=…>…</script>
Le premier est un script côté serveur et le second est un script côté client. Le premier est exécuté en premier et le second est exécuté plus tard.
En fait, ce n'est pas forcément le cas. Il est possible que les deux scripts soient exécutés en même temps, mais les espaces sont quand même différents : le premier est exécuté sur le serveur, et le second est exécuté dans le serveur. navigateur client. Le premier doit logiquement être exécuté plus tôt que le second. Dans le même temps, nous sommes également arrivés à la conclusion suivante : lors de l'exécution de la même page, le script côté client ne peut en aucun cas renvoyer le script côté serveur. Autrement dit, le client parcourt votre livre d'or et le soumet. les nouveaux messages ou toute valeur obtenue par le script côté client ne peuvent pas être traités dans la même réponse du serveur.
À propos des appels de composants
Notez que les scripts côté serveur et les scripts côté client sont tous deux des scripts. Naturellement, vous pouvez créer des composants xmlhttp, des composants ADODB.Connection, etc., mais ils ne peuvent être placés nulle part.
Si xmlhttp est utilisé pour explorer des pages Web (telles qu'une collection) à partir du serveur, il doit être créé dans le script du serveur. S'il est utilisé pour que l'ajax du client accède à la page côté serveur en arrière-plan sans actualiser, il s'exécute. sur le client, et bien sûr sur le client Créé à la fin.
Le composant ADODB.Connection est utilisé pour accéder à la base de données. De manière générale, il est créé côté serveur. Après tout, c'est le programme asp côté serveur qui exécute les données de la base de données, mais si votre base de données est réellement connectée sur le client. côté (comme celui-ci http://bbs .bccn.net/thread-224966-1-2.html), il doit alors être créé dans le script client.
Bref, des choses contradictoires et chaque camp a ses propres caractéristiques. Différentes choses ont différentes contradictions ; la même chose a différentes contradictions dans différents processus et étapes de développement ; différentes contradictions dans la même chose et deux aspects différents de la même contradiction ont chacun leurs propres particularités (vous pouvez omettre ceux qui ne comprennent pas) Don je ne regarde pas…). Ce principe nous oblige à adhérer au principe de l'analyse concrète de problèmes spécifiques et, sous la direction du principe d'universalité des contradictions, à analyser concrètement la particularité des contradictions et à trouver la méthode correcte pour les résoudre. Nous sommes opposés à l’utilisation d’une seule méthode pour résoudre les contradictions de différentes choses. Une clé ouvre une serrure, et c'est ce que signifie chanter n'importe quelle chanson que vous allez dans n'importe quelle montagne.
Les scripts VBScript côté serveur utilisent la méthode Server.CreateObject(className) pour créer des objets, et les scripts VBScript côté client utilisent la méthode CreateObject(className) pour créer des objets.
Erreurs typiques
<%
FonctionTTaille(b)
'C'est ma fonction personnalisée
TTaille=Chine
fonction de fin
%>
<a href=javascript:<%TSize('Variable')%> >Cliquez ici pour utiliser la fonction que j'ai définie</a>
(http://bbs.bccn.net/thread-225244-1-1.html)
Analyse des erreurs :
Confondre la différence entre les scripts côté serveur et les scripts côté client. Lors de l'exécution réelle, nous constaterons que le client ne reçoit aucun code tel que TSize, car TSize est un programme côté serveur qui est traité par le moteur (notez que le traitement des fonctions par le moteur est uniquement destiné aux scripts côté serveur). appels et ne seront pas renvoyés au client) disparaît et ne peut éventuellement pas fonctionner sur le client. Cela signifie que les scripts côté client ne peuvent pas appeler directement les fonctions des scripts côté serveur.
En fait, ce programme présente une erreur de syntaxe. Lorsque le moteur traite ce contenu, il trouve d'abord le contenu compris entre <% et %>, c'est-à-dire <%TSize('variable')%>. Évidemment, ce contenu n'est pas conforme. avec les règles de syntaxe VBScript. Eh bien, si vous le remplacez par <%=TSize(variable)%>, il n'y aura aucune erreur de syntaxe dans le script côté serveur. À ce stade, la fonction TSize peut renvoyer la valeur China normalement, donc l'attribut href reçu par. le client est écrit comme ceci : javascript : Chine, est inapplicable.
Impact des scripts côté serveur sur les scripts côté client
Comme mentionné précédemment, les scripts côté serveur sont logiquement exécutés avant les scripts côté client, donc un code comme celui-ci est réalisable :
<%
Faible je
Pour i=1 à 5
Réponse.Write <script type=text/javascript> _
& alert('Bonjour tout le monde ! & je & ')</script>
Suivant
%>
Concernant l'exécution de Response.Redirect et javascript
Notez que le code suivant est mal écrit :
<%
Réponse.Redirection index.asp
Réponse.Write <script type=text/javascript> _
& alert('Mauvais mot de passe !')</script>
%>
Il s'agit d'une erreur courante. Les écrivains pensent souvent qu'écrire du code de cette manière amènera le client à afficher une invite d'erreur de mot de passe, puis à le rediriger vers index.asp. En fait, cela ne peut pas se produire même dans l'ordre des deux lignes. le code est échangé, il ne le sera pas. Il est possible d'obtenir cet effet.
La raison est liée à la façon dont le serveur gère les deux lignes de code. Il est impossible que ces deux lignes de code fonctionnent en même temps.
Response.Write consiste à envoyer un morceau de texte au client.Le contenu de ce texte peut être un script. Ensuite, le navigateur client peut exécuter le script après l'avoir reçu.
Response.Redirect envoie un en-tête HTTP au client (qu'est-ce qu'un en-tête HTTP ? Disons-le de cette façon, par exemple, l'écriture dans les cookies du client est une information d'en-tête HTTP, et les informations d'en-tête HTTP sont renvoyées au client avant le corps HTTP du navigateur. , c'est pourquoi nous obtenons parfois une erreur lors de la modification des cookies après avoir désactivé la mise en mémoire tampon du serveur, car le corps a déjà commencé à transmettre et les en-têtes HTTP ne sont pas autorisés à être envoyés. informations.), le contenu des informations indique au navigateur client qu'il doit accéder à la page à parcourir. Notez que ces informations de redirection sont effectives immédiatement, ce qui signifie que ces informations de redirection sont exclusives lorsque le tampon est activé, quel que soit le cas. si Response a été utilisé. .Write écrit la quantité de contenu écrite dans le tampon. Une fois Response.Redirect appelé, le tampon sera effacé et cette instruction d'en-tête sera envoyée au navigateur client. Si nous suivons dynamiquement l'exécution du programme, nous constaterons également qu'après avoir appelé Response.Redirect, le programme cesse de s'exécuter, veuillez donc noter que le programme côté serveur doit fermer la connexion de données et les autres opérations avant d'appeler Response.Redirect.
Alors, comment modifier l’exemple ci-dessus ? Si vous ne souhaitez pas modifier le fichier index.asp pour ajouter une invite de script, vous pouvez uniquement exécuter l'instruction de redirection dans le script client, comme ceci :
<%
Réponse.Write <script type=text/javascript> _
& alert('!');location.href='index.asp'</script>
%>
Coordonnées
Si vous avez des commentaires et des suggestions, en particulier des erreurs et des lacunes dans l'article, ou si vous souhaitez ajouter du nouveau matériel à l'article, vous pouvez me contacter via le forum de programmation. Bien entendu, vous pouvez également poser des questions après ce post.
Il convient de mentionner que si vous avez des questions sur les algorithmes et les structures de données, par exemple ne pas comprendre pourquoi votre programme est erroné ou demander le code source d'un certain algorithme, vous risquez de ne pas obtenir de réponse rapide en utilisant ces informations de contact. Veuillez demander sur le forum de programmation.
-------------------------------------------------- ----------------------------------
droit d'auteur
Copyright (c) 2008 multiple1902
L'autorisation est accordée de copier, distribuer et/ou modifier ce document selon les termes de la licence de documentation libre GNU version 1.2 ou toute version ultérieure publiée par la Free Software Foundation.