Share
En esta serie, estamos en el proceso de hablar sobre cómo podemos crear aplicaciones web con WordPress. Y aunque esta no es una serie técnica en la que veremos el código, nosotros son cubriendo temas tales como marcos, fundaciones, patrones de diseño, arquitecturas, etc..
Si no has leído el primer post de la serie, lo recomiendo; sin embargo, a los efectos de este post, podemos resumir el post anterior de la siguiente manera:
En resumen, el software puede construirse sobre marcos, el software puede extender las bases.
En pocas palabras, diferenciamos los marcos y las bases, dos términos que a menudo se usan indistintamente en el software a pesar de que no son lo mismo. WordPress es una base porque es una aplicación en sí misma. No es un marco.
Para ese fin, cuando se trata de crear aplicaciones web en WordPress, necesitamos repensar la arquitectura o volver a considerar nuestros modelos conceptuales sobre cómo se construyen las aplicaciones..
En el nivel más alto posible, las aplicaciones web normalmente se estructuran con los siguientes tres componentes:
En términos generales, la capa de presentación es lo que el usuario ve y con lo que el usuario interactúa. Incluye todos los estilos, el código del lado del cliente y el marcado necesario para poner algo frente al usuario.
Cuando el usuario hace clic en algo, o la página muestra información recuperada de la base de datos, está interactuando con la capa de aplicación..
La capa de aplicación es responsable de coordinar la información del navegador y / o de la acción del usuario a la base de datos. A veces, esto consiste en escribir información en la base de datos, como información de un campo de formulario, para leer información de la base de datos, como recuperar la información de la cuenta de un usuario..
Al igual que la capa de presentación consta de diferentes componentes, como estilos, JavaScript, marcado, etc., la capa de aplicación puede consistir en una variedad de componentes diferentes, como los sistemas que son necesarios para leer y escribir datos en la base de datos. , validación de la información y cumplimiento de ciertas reglas que son exclusivas del problema en cuestión.
Finalmente, la capa de base de datos es donde se almacenan los datos. Puede consistir en el sistema de archivos, puede consistir en una base de datos MySQL, o puede consistir en una solución de terceros, como un almacén de datos que está "en la nube", como Amazon S3 o algo así..
El punto principal que se debe sacar de esto es que en el software, siempre estamos lidiando con algún nivel de abstracción. Por ejemplo, hablamos sobre el almacén de datos o la capa de base de datos, pero en realidad no estamos siendo específicos. Lo mismo ocurre con la capa de aplicación y la capa de presentación.
Obviamente, no estamos buscando dar respuestas a estas preguntas en este momento, pero el punto es que todas las aplicaciones web constan de componentes similares, pero los detalles de cada componente varían de un proyecto a otro..
Como una aplicación web en sí misma, WordPress es un ejemplo perfecto de cómo varias tecnologías se unen para formar una aplicación web:
Así que esa es la arquitectura de WordPress, pero ¿qué pasa con los proyectos que queremos construir sobre la aplicación? ¿Cómo siguen la misma arquitectura??
Bueno, recuerde que WordPress es una base, no un marco, por lo que estamos sujetos a la arquitectura de WordPress de forma predeterminada. Esto hace no significa que no podemos traer nuestras propias bibliotecas, en algunos casos, pero sí influye en la forma en que se construyen nuestras aplicaciones y proyectos.
Hablaremos más sobre las bibliotecas, la extensibilidad y más en un momento, pero primero, es importante tener en cuenta que en un día y edad donde MVC (y MVVM y otras variantes del paradigma Modelo, Vista, Lo que sea) son todos La rabia, WordPress lo hace. no sigue esa convención.
Hay argumentos a favor y en contra de por qué eso puede ser algo bueno o malo, pero ese no es el propósito de esta publicación. En su lugar, simplemente vale la pena señalar que WordPress utiliza un patrón controlado por eventos, en lugar del panel de control de vista de modelo..
Y para ese fin, vale la pena entender cómo funciona el modelo impulsado por eventos para que tenga una comprensión clara de cómo funcionan los enganches de WordPress, y cómo puede cambiar su idea de MVC o cualquier otro paradigma que esté acostumbrado a usar, Cómo WordPress gestiona su información..
Antes de echar un vistazo a un ejemplo de una aplicación basada en eventos, repasemos lo que significa seguir el paradigma MVC.
Todo el modelo MVC se ve así:
Ahora, las aplicaciones controladas por eventos pueden tener algunos de los mismos componentes, es decir, pueden tener vistas y modelos o vistas y objetos de datos, pero no necesariamente tienen un controlador que coordine la información desde el extremo frontal hasta el final..
En cambio, la programación dirigida por eventos funciona a partir de la premisa de que "algo sucedió". De ahí el nombre de comportamiento en la jerga de WordPress (por supuesto, también tenemos filtros, pero los cubriré momentáneamente).
WordPress proporciona enlaces que literalmente son puntos en ejecución en los que podemos introducir nuestra propia funcionalidad, de modo que WordPress lo reconoce "cuando este evento pasa, necesito disparar estas funciones" dónde estas funciones Se definen como lo que hemos proporcionado.
La verdad es que los filtros funcionan de la misma manera, pero su propósito es diferente. En resumen, los filtros son acciones que están diseñadas para manipular datos (como agregar, preparar, eliminar o actualizar el contenido) de alguna manera antes de volver a la ejecución de la aplicación..
Entonces, ¿cómo se ve esto??
Nada terriblemente complicado, ¿verdad??
El objetivo de este artículo es, principalmente, hacernos pensar en términos de programación dirigida por eventos y cómo coordinar nuestros esfuerzos de creación de aplicaciones web específicamente en WordPress..
Es decir, es importante para nosotros pensar en términos de eventos o el hecho de que "algo ha sucedido" para que sepamos cuándo insertar adecuadamente nuestras propias acciones. Hablaremos de esto un poco más en detalle en el próximo artículo, pero el punto principal que quiero que ustedes quiten de este artículo en particular es que simplemente porque algo no es MVC (o cualquiera que sea el próximo paradigma popular es ) no significa que no sea adecuado para el desarrollo de aplicaciones.
Cada patrón y arquitectura nos proporciona ventajas y desventajas, todo lo cual puede contribuir al éxito de la construcción de una aplicación web..
A continuación en la serie, veremos con más detalle cómo los enganches desempeñan un papel vital en la creación de aplicaciones web en WordPress, y luego comenzaremos a observar algunas de las instalaciones que WordPress ofrece de forma inmediata. que la convierten en una opción tan sólida para ciertos tipos (lea: no todos tipos) de aplicaciones web.
Accentsconagua