Langage de script Web côté serveur
Points clés de ce chapitre
·Comprendre les pages Web statiques et dynamiques
·Comparaison des langages de script côté client et côté serveur
·Introduction au langage de script côté serveur
Ce chapitre se concentre sur la discussion du langage de script côté serveur lui-même, et parle également de sa relation avec le HTML statique et les technologies générales côté client. À la fin de ce chapitre, les lecteurs auront une idée claire de ce que PHP peut et ne peut pas faire, ainsi qu'une compréhension générale de la manière dont il communique à l'origine avec le client.
HTML statique
La forme la plus basique de page Web est une page purement statique, contenant uniquement du texte, écrite entièrement en HTML. La simple page HTML de la figure 2-1 en est un exemple.
Langage de script Web côté serveur
Points clés de ce chapitre
·Comprendre les pages Web statiques et dynamiques
·Comparaison des langages de script côté client et côté serveur
·Introduction au langage de script côté serveur
Ce chapitre se concentre sur le langage de script côté serveur lui-même et parle également de sa relation avec le HTML statique et les technologies générales côté client. À la fin de ce chapitre, les lecteurs auront une idée claire de ce que PHP peut et ne peut pas faire, ainsi qu'une compréhension générale de la manière dont il communique à l'origine avec le client.
HTML statique
La forme la plus basique de page Web est une page purement statique, contenant uniquement du texte, écrite entièrement en HTML. La simple page HTML de la figure 2-1 en est un exemple.
Figure 2-1 Spécification de page Web HTML statique
Voici le code source de la figure 2-1 :
Comme le montre la figure 2-2, lorsque l'ordinateur client effectue une requête HTTP pour une page depuis le serveur via le Web ou Intantet, le serveur n'a qu'à transmettre le texte brut qui ne peut pas être trouvé dans le fichier.
Lorsque les données sont renvoyées à l'ordinateur client, le navigateur effectue le meilleur traitement et la meilleure présentation possible en fonction de son analyse précise du contenu du code source, des préférences de l'utilisateur, de la taille du moniteur et d'autres facteurs. Le contenu du fichier HTML sur le serveur est exactement le même que le code source de la page sur l'ordinateur client.
Le HTML statique très ordinaire comme le vôtre présente les avantages suivants :
◆ N'importe quel navigateur a la capacité de l'afficher.
◆La plupart des appareils ont la possibilité de l'afficher.
◆Il exécute chaque demande rapidement et utilise un minimum de ressources.
◆ Le HTML est facile à apprendre ou généré automatiquement.
◆ Possibilité d'apporter rapidement de petites modifications à des pages individuelles.
◆ Bien sûr, le HTML statique a aussi un inconvénient :
◆ Il est difficile de contrôler la conception et la mise en page.
◆ Impossible de s'adapter à un grand nombre de pages.
◆ L'interactivité n'est pas assez bonne.
◆ Il n'est pas facile d'inclure des métadonnées significatives sur la page.
◆ Difficulté à faire face à des changements rapides de contenu ou d'informations personnalisées.
◆ Pas très attractif.
Parce que... cela ne peut être considéré que comme un niveau "amateur" ou une application avec un certain idéal (cet idéal est aussi ferme qu'une page web écrite par certains experts en informatique, et ils pensons que toutes les pages Web doivent être conformes à la spécification HTML3.1 et doivent être lisibles par tous les appareils).
Pour remédier à ces limitations, de nombreuses autres technologies ont été développées, notamment JavaScript côté client, les feuilles de style en cascade (CSS) et les applets Java, ainsi que les langages de script côté serveur pour les connexions aux bases de données côté serveur. . Les technologies en cours de développement incluent XML et XSL, qui font tous deux partie de diverses autres spécifications (XHTML, XSLT, XPath, ICE, etc.).
Si vous prenez le temps de comprendre quelles fonctions ont ces technologies et si elles peuvent être ajoutées à votre propre site Web, vous réduirez certainement le risque de vous causer des maux de tête à l'avenir. Pour toute tâche Web à accomplir, la première question fondamentale à se poser est la suivante : où ce calcul est-il effectué, le client ou le serveur ?
La signification de « dynamique » Il existe une différence fondamentale et récurrente entre les pages Web « statiques » et « dynamiques », mais « dynamique » peut signifier presque tout sauf du HTML simple. Il est utilisé pour décrire à la fois les fonctionnalités côté client et les fonctionnalités côté serveur. Du côté de l'utilisateur, la « dynamique » peut être vue comme des affichages multimédias, des lignes de titres défilantes, des pages mises à jour automatiquement, ou des éléments qui apparaissent et disparaissent... etc. Côté serveur, le terme est généralement utilisé pour désigner un contenu transmis par voie hertzienne et assemblé de manière interactive.
Technologie côté client
Pour le HTML ordinaire, l'ajout de contenu le plus courant se produit côté client. Cela inclut les éléments suivants : des extensions de format telles que CSS et HTML dynamique, des langages de script côté client, des applets Java et Flash. La prise en charge de ces technologies est (pour la plupart) intégrée à la navigation Web. Le tableau 2-1 répertorie leurs fonctions, dont certaines se chevauchent.
Tableau 2-1 Extensions HTML côté client
L'exemple de page répertorié dans la figure 2-3 est basé sur le même contenu que la figure 2-1.
Comme vous pouvez le voir dans le code source, cet exemple ajoute de nouvelles feuilles de style, des scripts côté client et du code HTML plus complexe.
Malheureusement, le meilleur argument de vente des technologies côté client est aussi leur pire qualité : elles sont totalement dépendantes du navigateur. Les fonctions de chaque navigateur varient considérablement, même entre les différentes versions produites par la même marque. Chacun peut également choisir de configurer son navigateur de différentes manières. Par exemple, certaines personnes peuvent désactiver l'utilisation de JavaScript pour des raisons de sécurité, ce qui rend impossible la navigation sur des sites qui utilisent excessivement JavaScript pour la navigation. (Si nous montrons la fonction dans l'exemple précédent)
De plus, de nombreux utilisateurs obtiennent de mauvais résultats dans les mises à niveau du navigateur en raison du coût ou du manque de technologie. Les développeurs Web doivent avoir une compréhension de la navigation basée sur les appareils, des utilisateurs généraux et mondiaux, et bien plus encore. Sans exception, les sites Web destinés au grand public tentent de toucher le public le plus large possible. Par exemple, Yahoo! et Amazon ont insisté pour ne pas utiliser de feuilles de style et de JavaScript pendant plus de trois ans après avoir adopté ces normes. Sous la pression du W3C, de nombreux sites Web insistent encore obstinément sur l'utilisation de la balise FONT et des attributs BGCOLOR. Leurs clients peuvent être des utilisateurs qui utilisent AOL 3.0 sur de vieilles machines Macintosh avec des écrans à 13 heures. Ce qui est encore plus ironique, c'est que même après que le Web ait connu cinq années de développement rapide, la seule chose que les développeurs peuvent absolument garantir aux clients est qu'ils verront du HTML ordinaire, qui est principalement du texte brut. (Ou même un sous-ensemble de HTML qui a résisté avec succès et facilement à l'épreuve du temps)
Enfin, la technologie côté client ne peut effectuer aucun travail nécessitant une connexion à un serveur backend. JavaScript ne peut pas générer instantanément une liste déroulante personnalisée basée sur les options de préférences utilisateur stockées dans la base de données. Lorsque des modifications doivent être apportées à la liste, le développeur Web doit accéder à la page pour effectuer des modifications manuelles (JavaScript côté serveur, mais). il n'est pas utilisé actuellement. Trop) Pour ce problème, le langage JavaScript côté serveur est le sauveur qui peut combler cette lacune.
En bref, toutes les actions qui gèrent la configuration de la mise en page ou les événements du navigateur se produisent du côté de l'utilisateur. De manière générale, les effets sympas ou les choses qui dépendent du mouvement de la souris sont réalisés du côté de l'utilisateur. Vous pouvez constater que plus un événement apparaît rapidement, plus il est probable qu'il soit géré par le client, car des vitesses plus rapides signifient qu'il n'est pas nécessaire de le télécharger depuis le serveur.
Remarque :
Les applets Java, également connues sous le nom de « Java côté client », dépendent moins du navigateur que les autres technologies côté client. Comme leur nom l'indique, il s'agit de petites applications Java complètes livrées sur Internet. Cependant, contrairement aux applications écrites dans d'autres langages de programmation qui interagissent directement avec le système d'exploitation du client, les applets Java s'exécutent sur un logiciel appelé JVM (Java Virtual Machine). . Machine virtuelle, hôte virtuel Java) logiciel intermédiaire. JVM peut être considéré comme un système d’exploitation qui existe au-dessus d’un système d’exploitation réel. La plupart des navigateurs les plus récents auront une JVM, ce qui n'est pas suffisant. Bien sûr, vous pouvez également en télécharger une séparément pour l'utiliser. Cette distinction de fonctionnement permet à l'applet de permettre au navigateur d'exécuter des fonctions spéciales sans être limité par les capacités relativement faibles du navigateur.
Au début, les applets étaient considérées comme de petites choses dénuées de sens, car elles étaient à l'origine utilisées pour implémenter des animations simples, telles que des logos d'icônes qui ressemblaient à de la colle transparente, des barres de titre défilantes et des sauts de liaison, etc. . Heureusement, les applets ont évolué et peuvent être utilisées à des fins très humanistes, telles que les mots croisés, les simulations de la Tour de Hanoï, l'essai de costumes et d'accessoires et les modes virtuels.
Langage de script côté serveur
La figure 2-4 est un diagramme schématique du processus de données de script du serveur.
Le langage de script côté client est très attrayant et constitue la partie la plus accrocheuse du développement Web. La programmation côté serveur est tout le contraire. Elle est invisible pour l'utilisateur et cachée derrière lui. Les programmeurs de scripts côté serveur essaient toujours d'explorer les données sur le serveur Web principal, tandis que leurs collègues dotés de talents artistiques sur le front-end peuvent exprimer leurs travaux devant le public.
Le langage de script du Web côté serveur connecte principalement le site Web au serveur back-end, tel qu'une base de données, ce qui permet une communication bidirectionnelle :
Le script langage du Web côté serveur Le langage de script connecte principalement le site Web au serveur back-end, tel qu'une base de données, ce qui permet une communication bidirectionnelle :
◆ Serveur à client : les pages Web peuvent être combinées à partir de la sortie du serveur back-end.
◆ Client vers serveur : Rendre efficace la saisie des informations par le client.
Des exemples courants de communication utilisateur-serveur sont les formulaires en ligne et certaines listes déroulantes qui sont combinées dynamiquement sur le serveur. (Habituellement, vous devez appuyer sur un bouton).
Le produit de langage de script côté serveur comprend deux parties principales : le langage de script et le moteur de script (qui peut ou non être intégré au serveur Web). Les pièces du moteur sont toutes développées par la même entreprise ou équipe et ne peuvent être utilisées que conjointement les unes avec les autres (PHP3 et ColdFusion en sont deux exemples). Il existe cependant des exceptions à cette règle : par exemple, les pages Java Server sont écrites dans des langages de programmation standards plutôt que dans des langages de script spécialisés ; certains partenaires ont développé plusieurs moteurs compatibles et interchangeables (comme Allaire JRun, Apache JServ).
Théoriquement, Active Server Pagesb permet l'utilisation de la plupart des langages de script et de l'un des nombreux moteurs de script ActiveX correspondants (cependant, en pratique, à l'exception de la combinaison NT/IIS/VBScript/JScirpt. De plus, il existe de nombreux problèmes avec d'autres combinaisons). Puisque le moteur de scriptingz de PHP4 (Zend) est actuellement théoriquement séparé du langage de programmation PHP, PHP4 est désormais considéré comme une technologie de script distincte et indépendante.
La figure 2.5 répertorie un exemple de langage de script simple côté serveur. Basé sur le code source côté serveur et le code source côté client, une page est instantanément générée à partir de la base de données. Nous avons inclus les appels à la base de données (que nous n'entrerons pas dans les détails avant la deuxième partie de ce livre) et omis certains des fichiers inclus car le but de cet exemple est de montrer le produit final de PHP, et non d'être un modèle formel. Le code source exécutable du travail utilise
Ce qui suit est le code source sur le serveur
Il s'agit du formulaire de présentation du code source de la même page lorsqu'il atteint le client :
Le ci-dessus se trouve le guide d'apprentissage PHP - Chapitre 2. Pour plus de contenu connexe, veuillez prêter attention au site Web PHP chinois (m.sbmmt.com) !