Share
Dans cette série, nous sommes en train de discuter de la manière dont nous pouvons créer des applications Web à l'aide de WordPress. Et bien que ce ne est pas une série technique dans laquelle nous allons examiner le code, nous sont couvrant des sujets tels que les cadres, les fondations, les modèles de conception, les architectures, etc..
Si vous n'avez pas lu le premier billet de la série, je le recommande. Cependant, pour les besoins de ce post, nous pouvons résumer le post précédent comme suit:
En bref, les logiciels peuvent être construits sur des frameworks, les logiciels peuvent étendre des fondations.
En termes simples, nous avons différencié les frameworks et les fondations - deux termes qui sont souvent utilisés de manière interchangeable dans les logiciels, en dépit du fait qu’ils ne sont pas la même chose. WordPress est une fondation car c'est une application en soi. Ce n'est pas un cadre.
À cette fin, lorsqu’il s’agit de créer des applications Web sur WordPress, nous devons repenser l’architecture ou repenser nos modèles conceptuels pour la manière dont les applications sont construites..
Au niveau le plus élevé possible, les applications Web sont normalement structurées avec les trois composants suivants:
De manière générale, la couche de présentation est ce que l'utilisateur voit et avec lequel il interagit. Il inclut tous les styles, le code côté client et les balises nécessaires pour mettre quelque chose devant l'utilisateur..
Lorsque l'utilisateur clique sur quelque chose ou que la page rend des informations extraites de la base de données, cela interagit avec la couche application..
La couche d'application est responsable de la coordination des informations du navigateur et / ou de l'action de l'utilisateur vers la base de données. Parfois, cela consiste à écrire des informations dans la base de données - telles que les informations d'un champ de formulaire - pour lire des informations à partir de la base de données, telles que la récupération des informations de compte d'un utilisateur..
Tout comme la couche présentation comprend différents composants (styles, JavaScript, balisage, etc.), la couche application peut être composée de nombreux composants, tels que des systèmes nécessaires à la lecture et à l’écriture de données dans la base de données, ainsi que la désinfection des informations. , validation des informations et application de certaines règles propres au problème à résoudre.
Enfin, la couche de base de données est l'endroit où les données sont stockées. Il peut s'agir d'un système de fichiers, d'une base de données MySQL ou d'une solution tierce, telle qu'une banque de données "dans le nuage", telle qu'Amazon S3, ou quelque chose du genre..
Le point principal à retenir est que dans le logiciel, nous avons toujours affaire à un certain niveau d’abstraction. Par exemple, nous parlons du magasin de données ou de la couche base de données, mais nous ne sommes pas vraiment spécifiques. Idem pour la couche application et la couche présentation.
Évidemment, nous ne cherchons pas à répondre à ces questions pour le moment, mais le fait est que toutes les applications Web sont constituées de composants similaires, mais les détails de chaque composant varient d'un projet à l'autre..
En tant qu'application Web, WordPress est un exemple parfait de la façon dont diverses technologies se combinent pour former une application Web:
C'est donc l'architecture WordPress, mais qu'en est-il des projets que nous souhaitons construire par-dessus l'application? Comment suivent-ils la même architecture?
Eh bien, rappelez-vous que WordPress est une base - pas un cadre - nous sommes donc soumis à l'architecture de WordPress par défaut. Cela fait ne pas Cela signifie que nous ne pouvons pas importer nos propres bibliothèques, dans certains cas, mais cela influence la manière dont nos applications et nos projets sont construits..
Nous parlerons davantage des bibliothèques, de l’extensibilité et d’autres choses dans un instant, mais d’abord, il est important de noter que dans un jour et l’âge où MVC (et MVVM et d’autres variantes du paradigme Modèle, Vue, Peu importe) sont tous la rage, WordPress fait ne pas suivre cette convention.
Il y a des arguments pour et contre pourquoi cela peut être une bonne ou une mauvaise chose, mais ce n'est pas le but de cet article. Au lieu de cela, il convient simplement de noter que WordPress utilise un modèle basé sur les événements, plutôt que le panneau modèle-vue-contrôle.
Et à cette fin, il est utile de comprendre le fonctionnement du modèle basé sur les événements afin de bien comprendre le fonctionnement des points d'ancrage WordPress et de changer de paradigme auquel vous pensez par rapport à MVC, à la façon dont WordPress gère ses informations.
Avant d'examiner un exemple d'application pilotée par les événements, revenons à ce que signifie suivre le paradigme MVC..
L'ensemble du modèle MVC ressemble à ceci:
À présent, les applications événementielles peuvent avoir certains des mêmes composants, c’est-à-dire qu’elles peuvent avoir des vues et des modèles ou des vues et des objets de données, mais elles n’ont pas nécessairement de contrôleur qui coordonne les informations du début à la fin..
Au lieu de cela, la programmation événementielle part du principe que "quelque chose est comme ce qui s'est passé". D'où le nom de actes dans le jargon WordPress (bien sûr, nous avons aussi des filtres, mais je couvrirai ceux-ci dans un instant).
WordPress fournit des points d'accroche qui sont littéralement des points d'exécution, dans lesquels nous pouvons introduire notre propre fonctionnalité, de sorte que WordPress reconnaisse que " cet evènement arrive, j'ai besoin de tirer ces fonctions" où ces fonctions sont définis comme tout ce que nous avons fourni.
La vérité est que les filtres fonctionnent de la même manière, mais leur objectif est différent. En bref, les filtres sont des actions destinées à manipuler des données (telles que l’ajout, la préfixe, la suppression ou la mise à jour du contenu) d’une manière ou d’une autre avant de revenir à l’exécution de l’application..
Alors à quoi ça ressemble?
Rien de bien compliqué, c'est ça?
Le but de cet article est principalement de nous amener à penser en termes de programmation événementielle et de coordonner nos efforts pour créer des applications Web spécifiquement sur WordPress..
C’est-à-dire qu’il est important pour nous de penser en termes de événements ou le fait que "quelque chose est arrivé" pour que nous sachions quand insérer correctement nos propres actions. Nous en parlerons un peu plus en détail dans le prochain article, mais le point principal que je voudrais que vous reteniez de cet article, c'est que, simplement parce que quelque chose n'est pas MVC (ou quel que soit le prochain paradigme populaire) ) ne veut pas dire qu'il n'est pas bien adapté au développement d'applications.
Chaque modèle et architecture nous offre des avantages et des inconvénients qui peuvent tous contribuer au succès de la création d’une application Web..
Dans la prochaine partie de la série, nous examinerons plus en détail le rôle essentiel que jouent les crochets dans la création d’applications Web sur WordPress, puis nous examinerons certaines des fonctionnalités offertes par WordPress. qui en font une option si solide pour certains types (lire: pas tout types) d'applications Web.
Accentsconagua