Le concept d’événementiel est large. Cela peut être côté client ou côté serveur.
Dans les applications WEB, les événements côté client sont basés sur du JS ou des plug-ins ou JAVAAPPLET. En gros, s'il s'agit d'un plug-in ou de JAVAAPPLET, il n'appartient pas à la catégorie du HTML. En fait, les occasions où doivent être JS. utilisés sont en fait Il n'y en a pas beaucoup, tout au plus ce sont des opérations de base telles que la soumission d'un FORMULAIRE ou des clics sur un lien, donc parler d'événements n'a aucun sens.
Le véritable sens de l’événementiel ne réside pas dans la programmation visuelle, mais dans son concept, tout comme l’OO. La gestion des événements est en fait une extension d'OO, et son prototype original est le mécanisme de message. Mais le pilote d'événement encapsule le message dans une fonction appelable, similaire à la fonction de rappel de l'API. Vous pouvez définir vous-même le contenu d'exécution de ces fonctions. La programmation visuelle sépare ces fonctions, définit des paramètres (principalement des objets prêts à l'emploi) et vous permet d'écrire votre propre code et d'utiliser ces paramètres (en fait, ces objets) pour faire quelque chose.
Par conséquent, il est tout à fait possible que PHP soit piloté par les événements, principalement en raison de la conception du framework. Pour créer un pilote d'événement visuel tel que VB, vous devez disposer d'un environnement de développement intégré de support, comprenant une série de fonctions telles que la conception de pages, l'encodage d'événements, la compilation et le transcodage. En fait, ceux basés sur des événements comme NET encapsulent simplement certains éléments ou contrôles WEB couramment utilisés, tels que des boutons, des zones de texte, etc., afin que vous puissiez avoir une interface visuelle à concevoir. Une fois compilée, c'est toujours du texte comme celui-ci. , convertissez simplement votre code d'événement en JS ou en code côté serveur. Pour PHP, la raison principale est que l'IDE n'est pas assez riche et qu'il n'y a pas de mécanisme de pré-compilation, donc le code final soumis est toujours le code PHP final, plutôt qu'un mélange de code de ressource NET et de code d'événement (généralement un code ASP). document conforme à la spécification XML. Contient du code HTML non standard). Par conséquent, PHP n'est toujours pas en mesure de réaliser dans l'esprit de tous la programmation dite événementielle au sens étroit du terme, mais en fait, cela se fait sans aucun problème.
Si vous êtes intéressé, vous souhaiterez peut-être vous rendre sur la page d'accueil officielle de www.php.net pour jeter un œil à PRADO, un framework PHP événementiel écrit par un ami chinois (Qiang Xue). C'est toujours le meilleur qui soit. a reçu des votes élevés et est fortement recommandé ! Veuillez vous référer à http://www.zend.com/php5/contest . Après avoir lu son code source, vous comprendrez ce qu'est le pilote d'événement PHP. Mais je pense qu'à cet égard, parce que PHP n'a pas de mécanisme de pré-compilation et s'appuie trop sur OO (même si le code est écrit en PHP5), ce framework est un peu volumineux, compliqué à utiliser et peu évolutif. Cependant, les concepts sont très bons et certaines idées ont résolu des problèmes qui me laissaient perplexe depuis plusieurs jours. Permettez-moi de présenter brièvement ce cadre ci-dessous.
Le framework est écrit en ZDE et PHP5. Il possède une documentation détaillée, une structure très claire et suffisamment de commentaires. Le code est très facile à lire, indiquant que le niveau de codage de l'auteur est très élevé. L'auteur a clairement indiqué que ce framework fait référence aux concepts d'ASP.NET et de Borland Delphi.
Ce cadre est très solide en matière de vérification (même s'il existe des modules tels que la connexion de vérification), très robuste et il est presque impossible d'avoir des failles directes pouvant être pénétrées de l'extérieur. Il introduit le concept de fichiers de spécification. , cela résout efficacement le goulot d'étranglement d'efficacité dans la vérification à grande échelle. Le seul problème avec cette méthode de vérification est que la production du fichier de spécification lui-même est plus laborieuse (bien sûr, l'utilisation d'outils est une autre affaire). le fichier de spécification lui-même (avec formats et spécifications), la vérification est naturellement effectuée par le framework sans avoir besoin d'appels humains à chaque fois. Ses événements peuvent également être définis dans le fichier de spécification (je pense que ce n'est pas nécessaire). En fait, son fichier de spécification est quelque peu similaire au fichier de définition FORM en DELPHI ou VB, mais il s'agit de texte brut écrit en XML. visualisation. En ce qui concerne les événements, le framework dispose d'un ensemble intégré de flux d'événements de base similaires à NET. Vous pouvez personnaliser ces événements à différentes étapes. En fait, pour parler franchement, cela signifie redéfinir ces fonctions OnXXX et utiliser des paramètres dans un. sous forme donnée. Vous pouvez également ajouter vos propres événements. Par exemple, lorsque vous définissez votre propre composant, définissez les fonctions d'événement et les paramètres que le composant peut avoir dans le fichier de spécification. À l'avenir, vous pourrez définir directement ces fonctions autorisées. lors de l'utilisation du composant - mais je pense que cette méthode est trop compliquée et nécessite la lecture et l'analyse d'un grand nombre de fichiers XML. Bien qu'elle soit très rigoureuse et sûre, elle est un peu excessive et n'utilise pas pleinement la flexibilité de PHP lui-même. Mon idée est d'utiliser quelque chose de similaire à DELPHI. En attribuant des descripteurs de fonction ou en utilisant les fonctionnalités de la fonction de rappel de C, vous pouvez définir des événements à tout moment et n'importe où lors de l'écriture du code, tout en étant capable d'identifier clairement l'expéditeur et le type d'événement. des garanties de sécurité suffisantes sans avoir besoin de machines. Cela force effectivement chaque composant à n'avoir que certains événements, ce qui rend la modification et l'expansion du code très pratiques. Bien sûr, lorsque l'on travaille sur de grands projets, des définitions strictes sont nécessaires, mais malgré cela, la manière dont le framework gère les événements est quelque peu démodée.
Je pense que son modèle est une meilleure idée. Son modèle est quelque peu similaire au fichier ASP de NET avant la compilation (je ne suis pas familier avec ASP NET, mais je comprends certains principes), mais la façon dont il fonctionne est un fichier FORM similaire à DELPHI. est un très bon concept. Le seul inconvénient est qu'il n'est pas très pratique d'utiliser un éditeur général WYSIWYG tel que DW, car plusieurs composants mutuellement exclusifs peuvent être combinés dans un seul modèle en même temps et décider lesquels afficher uniquement. pendant l'exécution.
Quand je regarde le code de ce framework, je trouve toujours qu'il contient des éléments très faibles. Le plus important est le problème du chemin. L'évolutivité est très faible. Il devrait être plus adapté aux hôtes dédiés. Vous ne pouvez rien faire contre certains hôtes restreints (restrictions de répertoire ou restrictions d'autorisation), et il n'y a pas de mesures de rappel correspondantes ( et aucune interface associée). Il utilise un mécanisme fastidieux appelé AssetService pour le chemin de certaines ressources ou fichiers. Le but est de déterminer le chemin du fichier. L'auteur lui-même a également déclaré que si ce service est utilisé, la consommation du système augmentera considérablement. emprunté à Le concept de bibliothèque d'actifs dans FLASH permet de spécifier le chemin arbitrairement, mais il doit être revérifié à chaque fois, ce qui n'en vaut pas le gain. Mon approche consiste à corriger plusieurs chemins principaux, et leurs sous-répertoires peuvent être arbitraires, ce qui équilibre complètement la contradiction entre les deux. En raison du manque de prise en compte des problèmes de cheminement, le framework est impuissant avec les paramètres de langue, les modèles personnalisés, etc. Si vous souhaitez traduire un projet, il est concevable que les procédures soient compliquées, la charge de travail énorme et il est facile de traduire un projet. faire des erreurs. C’est le problème le plus grave du cadre.
D'une manière générale, le concept, la conception et le code de ce framework sont absolument de premier ordre. Bien sûr, il y a toujours des lacunes, mais cela ne nous empêche pas du tout de l'étudier et de l'apprendre. Je n'ai pas lu tout son code, seulement quelques programmes de base et quelques instructions, mais je vois clairement sa structure et ses idées. J'admire profondément l'auteur, mais je regrette aussi profondément les lacunes. Quoi qu'il en soit, c'est certainement un bon travail pour étudier le code événementiel PHP. Donc fortement recommandé !