En este curso intentare mostrar la combinación de archivos que necesitas para un modulo personalizado en donde puedas combinar distintos archivos tanto clases en PHP como archivos de configuración en XML, cuando me inicie en el desarrollo de Magento 2 se me complicaba entender como se comunicaban las clases contra las vistas y los archivos XML de templates contra los Bloques, como resolvían los nombres de URL para saber como llamar a los controladores de principio si no eres un experimentado de algún FrameWork de desarrollo todos estos conceptos te podrían generar confusión pero como de costumbre intentare explicarlo de la forma que a mi me hubiera agradado que alguien en el pasado me lo hubiera explicado de tal forma.

Pensemos en una tienda propia en donde se nos ha pedido mostrar en pantalla una pagina personalizada que muestre las politizas de privacidad de nuestro sitio, en una URL que nosotros llamemos politicas-de-privacidad este sera el nombre de la URL cuando coloquemos en nuestro navegador http://web.marcgento.com/politicas-de-privacidad en donde web.marcgento.com se refiera al nombre principal de nuestro pagina de Internet, inmediatamente que coloquemos y ejecutemos esta URL se mostrara una Pagina con un gran titulo y contenido en su interior.

con esta curso conseguiremos entender la estructura de un Modulo que contenga un Router que sera el indicador de la URL (politicas-de-privacidad), Un llamado a un primer Controlador una clase de PHP que en conjunto con una Vista indicada en un archivo de configuración XML le indicaría cual es esa Vista que resolverá nuestro controlador, en concreto estaremos hablando de un Modelo MVC modelo vista controlador, y par aquellos que ya conozcan de programación orientada a objetos lo entenderán mejor.

con esta curso conseguiremos entender la estructura de un Modulo que contenga un Router que sera el indicador de la URL (politicas-de-privacidad), Un llamado a un primer Controlador una clase de PHP que en conjunto con una Vista indicada en un archivo de configuración XML le indicaría cual es esa Vista que resolverá nuestro controlador, en concreto estaremos hablando de un Modelo MVC modelo vista controlador, y par aquellos que ya conozcan de programación orientada a objetos lo entenderán mejor.

• app/code/Marcgento (Nombre de nuestra empresa)
• app/code/Marcgento/PoliticasPrivacidad (Nombre de nuestro Modulo)
• app/code/Marcgento/PoliticasPrivacidad/etc (Carpeta de archivos XML de configuración)

Vamos a crear un archivo XML de configuración module.xml que sirve para que nuestro modulo pueda existir en Magento este debe crearse dentro de la carpeta etc ya creada en la estructura de carpetas quedando de la siguiente forma app/code/Marcgento/PoliticasPrivacidad/etc/module.xml y contendrá este contenido:

Vamos a crear ahora un Script en PHP que es el que se encargara de registrar el modulo, para esto crearemos un archivo llamado registration.php que estará dentro de la ruta principal del modulo quedando de esta forma app/code/Marcgento/PoliticasPrivacidad/registration.php y contendrá el siguiente contenido:

bin/magento cache:clean
bin/magento setup:upgrade

Mediante la ejecución de los comandos ya mencionados y si todo se ha realizado conforme a lo indicado nuestro modulo ya podrá existir en nuestro proyecto, a través de las versiones que han pasado por Magento han actualizado muchas secciones con la idea de mejor el trabajo de los administradores así como la de los desarrolladores, anteriormente en versiones pasadas se podía ir al BackEnd y encontrar una sección de Módulos que indicaban cuales estaban registrados y activos, pero en la versión que actualmente trabajo que es la 2.3 ya no esta esa sección así que para confirmar que el modulo esta dado de alto de forma correcta lo que actualmente utilizo desde la linea de comandos de Magento es el siguiente comando: bin/magento module:status este comando nos mostrara un lista de todos los módulos registrados en el proyecto y algo mucho mejor nos indicara cuales esta habilitados y cuales deshabilitados.

Es importante aclarar en este punto justo en la ejecución de los comandos, que esto es algo que se agrego en la versión de Magento 2 por un lado para que ya no se dependiera de herramientas externas por ejemplo como en la versión 1 que se podía utilizar n98magerun o wiz que eran componentes como consola que permitían realizar ejecuciones y programaciones para las tareas repetitivas que normalmente se realizan en unas serie de pasos definidos, Magento 2 creo su propia consola la CLI de Magento 2.

Para los que saben de MVC modelo vista controlador sabrán que un controlador es la clase principal del patrón MVC como en la teoría dice, del conjunto de un Modelo una Vista y un Controlador se consigue cumplir con el patrón de programación, desarrollar 2 archivos de clase en PHP, mas uno que contendrá código HTML como de una pagina cualquiera con código embebido de PHP comunicados entre si para que cada uno realice la función para la que fue creado.

En mi propias palabras diría si requiero crear una pagina cualquiera en este caso y siguiendo con el ejemplo voy a crear la pagina de políticas de privacidad de la tienda, pues claro lo que necesito es un archivo que represente mi pagina web de Políticas de Privacidad que contendría un encabezado, un titulo un contenido y un pie de pagina tal vez podría hacerlo creando un simple archivo en HTML, esto seria algo bastante sencillo de hacer pero no estamos hablando de paginas web sencillas si no de la implementación de un patrón de diseño que Magento ha integrado en su plataforma así que lo que necesitamos entender es,cambiemos la idea de que es una pagina sencilla en HTML por una clase en PHP que al construirla con las indicaciones que define Magento esta seria la misma pagina pero funcionando con el patrón de diseño que ya tienen Magento así que vamos a ello crearemos nuestro Controlador para mi el controlado representa la clase base de una pagina web en cuanto coloquemos en nuestro navegador la URL /politicas-de-privacidad en ese momento lo primero que se ejecutara sera esta clase de controlador así es como funciona.

El contenido de nuestro clase en PHP y que representa nuestro Controlador se creara con el nombre Index.php que ira dentro de una carpeta llamada Controller\Index localizada en la ruta app/code/Marcgento/PoliticasPrivacidad/Controller/Index/Index.php su contenido sera el siguiente:

Pero antes de eso vamos a ver como quedaría la estructura de carpetas para el Controlador seria de la siguiente manera:

• app/code/Marcgento/Controller/Index

Si nuevamente ejecutamos desde la consola de Magento los comandos bin/magento c:f así como también bin/magento setup:upgrade y finalmente en nuestro navegador colocamos la URL http://marcgento.local/politicas-de-privacidad notaremos que se mostrara una página en blanco como se muestra la siguiente imagen:

Si lo que vemos es una página en blanco, esto es una señal de que todo lo hemos hecho bien ya que de lo contrario nos estaría mostrando un mensaje de error.

Que es lo que está pasando hasta este punto, lo que se ha configurado desde nuestro archivo de configuración routes.xml es un frontName esto es dar de alta una URL con el valor indicado en ese parámetro, en este caso es la URL politicas-de-privacidad hay que ser cuidadosos con este parámetro ya que estamos hablando de una URL que resolverá un navegador web así que no debería tener caracteres especiales o espacios entre la declaración del nombre, una vez que ya sabemos esto veamos cómo se conecta el Router con el Controller y es algo que es sencillo pero al mismo tiempo puede verse confuso así que tratare de explicarlo, hay funcionalidad nativa en Magento que sabe cómo conectar cada Router con su respectivo Controlador que es lo que sucedió con nuestro ejemplo al colocar la URL en realidad lo que se ejecuto fue el Controlador ya creado localizado en la ruta app/code/Marcgento/PoliticasPrivacidad/Controller/Index/Index.php aquí cabe mencionar algo muy importante Absolutamente todos los controladores por regla general deben contener un método llamado execute() que este será el método que se ejecuta por defecto, segundo un controlador debe extender la clase \Magento\Framework\App\Action\Action con estas dos indicaciones por ahora es suficiente ahora a lo que corresponde como sabe el Router cuál es el Controlador que debe ejecutar y me iré por lo más sencillo si miramos nuevamente la URL que hemos utilizado http://marcgento.local/politicas-de-privacidad nos muestra la página en blanco y ahora va lo interesante si colocamos nuevamente la misma URL pero ahora agregando lo siguiente al final quedando de esta forma http://marcgento.local/politicas-de-privacidad/index/index y miramos nuevamente nos seguirá mostrando una misma página en blanco pero estamos hablando de que el ruteo sigue siendo el mismo, y lo que ha pasado es que la funcionalidad interna de Magento define que si no especificamos nada después de la URL definida en el frontName del routes.xml entonces Magento por default da por hecho que la URL completa será http://marcgento.local/politicas-de-privacidad/index/index.

Como está representada una URL de ruteo en Magento de la siguiente forma:

1. Primero debe existir una definición de un frontName en este caso es políticas-de-privacidad
2. Segundo debe existir un nombre de Carpeta dentro de la Carpeta Controller indicando el nombre de controlador al cual debe resolver en este caso es Index
3. Tercero debe existir la clase final que indicara cual es el controlador que deberá resolver, que en este caso es el script de PHP Index.php

Así que la formula está construida por frontName + Carpeta Controlador + Nombre de Clase cada una separadas por una diagonal “ / ”

Pero para los que se pregunta qué paso en el ejemplo realizado cuando no se indicaron los parámetros de carpeta controlador ni del script de clase del controlador, pues la respuesta es sencilla si no indicamos esos parámetros en la URL lo que Magento ejecuta de forma automática es que iría a buscar una carpeta Controlador llamada Index y dentro una clase de script llamada Index.php de esta forma construye automáticamente la URL final y sabe cómo resolver el Controlador, si alguno de esos archivos no existiera o no se hubiera nombrado como Index entonces si se mostraría un mensaje de error indicando que no existe dicho archivo o carpeta.

Otro caso sería si tenemos una clase de Controlador llamada Form.php la URL debería colocarse de la siguiente forma http://marcgento.local/politicas-de-privacidad/index/form y dentro de la ruta app/code/Marcgento/PoliticasPrivacidad/Controller/Index debería estar la clase Form.php.

Vamos a realizar algunos ajustes a la clase del controlador para que esté lista para aceptar el layout el diseño de nuestra página, vamos a abrir la clase localizada en la ruta app/code/Marcgento/PoliticasPrivacidad/Controller/Index/Index.php quedando de la siguiente forma:

Ahora ya está teniendo sentido nuestro modulo ya nos refleja una página respetando los elementos por defecto de la plantilla nativa de Magento como lo es el Header, Footer y Menu de navegación y esto es gracias a la clase \Magento\Framework\View\Result\PageFactory que justamente se encarga de ejecutar un render para que la pagina pueda construir una página Master del proyecto aunque no tenga un Layout template vinculado enseguida veremos cómo vincular un Témplate a la página que está representado por archivos .phtml que definen la Vista de la página.

Lo que crearemos es un archivo de configuración de Plantilla (Layout) que servirá para vincular la Vista de nuestro controlador así como una clase de Bloque para nuestra vista.

• lo primero que realizaremos es crear una carpeta llamada view quedando de la siguiente forma: app/code/Marcgento/PoliticasPrivacidad/view
• en segundo lugar vamos a crear una segunda carpeta llamada frontend quedando de la siguiente forma: app/code/Marcgento/PoliticasPrivacidad/view/frontend
• en tercer lugar vamos a crear una carpeta llamada layout quedando de la siguiente forma: app/code/Marcgento/PoliticasPrivacidad/view/frontend/layout
• y finalmente ahora si crearemos nuestro archivo XML de vinculación de la vista con el controlador llamado politicasprivacidad_index_index.xml con el siguiente contenido:

  Aquí hay algún par de cosas interesantes que debes saber, que ahora recuerdo cuando estaba aprendiendo a crear esto de los controladores con las configuraciones (layout) XML y las vista (templates) .phtml se me hacía muy enredoso como es que cada controlador sabe con qué XML y vista (View) debe ir y más aún como debería nombrar cada XML para que este sepa a qué controlador corresponde, así que tratare de explicarlo de la mejor forma posible.

  Recuerdas el Router el archivo routes.xml que creamos pues ahí está la clave principal si miramos nuevamente ese archivo XML de configuración vamos a notar que en su nodo route hay un atributo id llamado politicasprivacidad este nombre es el primer parámetro con el que debemos nombrar a nuestros Layout XML seguido del Nombre de la carpeta del controlador la que está dentro de Controller y finalmente el nombre de la Clase controlador mejor conocida como la Acción solo no olvidando que cada palabra debe ir separada por un guion bajo “_”, pues bien para el controlador del ejemplo que está en la ruta app/code/Marcgento/PoliticasPrivacidad/Controller/Index/Index.php para este controlador así como lo acabo de explicar el archivo Layout que deberíamos crear dentro de la ruta app/code/Marcgento/PoliticasPrivacidad/view/frontend/layout/ seria politicasprivacidad_index_index.xml, pues ahora bien si tuviésemos otra clase de controlador llamada Form.php el XML (layout) debería nombrarse politicasprivacidad_index_form.xml claro tendríamos una clase controlador almacenado en la ruta app/code/Marcgento/PoliticasPrivacidad/Controller/Index/Form.php y su XML de Layout estaría creado en app/code/Marcgento/PoliticasPrivacidad/view/fronend/layout/politicasprivacidad_index_form.xml ahora si ya va quedando más claro cómo es que se vinculan y relacionan los controladores con los Layout enseguida pasaremos a la Vista .phtml.

Lo que corresponde ahora es crear la vista que acabamos de indicar en el archivo de Layout politicasprivacidad_index_index.xml como podemos ver en el nodo block el atributo template indica la ruta de un archivo con extensión .phtml que representara la Vista vinculada para el controlador indicado por este XML de configuración, es muy fácil notar la nomenclatura con la que se manda a llamar un archivo .phtml, ya que se indica el espacio de nombre Marcgento seguido del nombre del módulo PoliticasPrivacidad separados por un guion bajo “_” y posterior la nomenclatura de referencia de doble puntuación “::” seguido del nombre que le demos a nuestro archivo PHTML que será localizado en la ruta app/code/Marcgento/PoliticasPrivacidad/view/frontend/view/templates/ con el nombre indicado políticas-de-privacidad.phtml cabe recordar que este es un nombre de URL valido así que hay que tener cuidado en nombrar a estos archivos .phtml, el contenido lo podremos ver a continuación:

Politica de Privacidad

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry’s standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.

Voy a intentar explicar para que sirven las clases de Bloque dinámicas para lo cual recordemos que en nuestro archivo Layout llamado politicasprivacidad_index_index.xml en su nodo block atributo class se indicó la ruta de una Clase de bloque mejor conocida como las clases de bloque dinámicas, pues para no hacer tanta confusión por ahora lo diré de esta forma si hablamos de un patrón de diseño MVC modelo vista controlador nos dice que se trata de separar el controlador de la vista y el modelo del controlador y la vista cada uno se maneja en archivos distintos para los controladores son clases PHP para las vistas son archivo PHTML ya vimos que para que estos puedan vincularse y saber cual les corresponde se realiza mediante archivos de configuración en XML, y bien entendiendo todo esto como será capas la Vista .phtml mostrar funcionalidad dinámica que venga de Base de datos, de algún componente de alguna acción programada en PHP pues bien aquí es donde entra el trabajo de las clases de bloque dinámicas quien serán las encargadas de pasarle a la vista esa información dinámica, en la siguiente lección realizaremos una pequeña prueba pasándole un título dinámico creado en la clase dinámica de bloque a la vista para que quede un poco más claro esto y ¿por qué debe ser así? Por el simple hecho de que se intenta al por mayor tener bien separada toda la lógica de programación del lado de las clases dinámicas y solo dejar en la vista el código más limpio y necesario que necesite para mostrar información tanto estática como dinámica.

Vamos a crear la clase de bloque dinámica para lo cual lo primero es crear una carpeta en nuestra estructura del módulo llamada Block quedaría de esta forma app/code/Marcgento/PoliticasPrivacidad/Block posterior ahora si crearemos la clase llamada PoliticasPrivacidad.php quedaría de esta forma app/code/Marcgento/PoliticasPrivacidad/Block/PoliticasPrivacidad.php que contendría este contenido:

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry’s standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.

¿De dónde ha salido la variable $block definida en la vista? pues es nada más ni nada menos en lo que ha trabajado ya Magento de forma nativa, para los que ya conocían de Magento 1 en aquel entonces el poder llamar a un método de nuestras clases de bloque (Block) había que colocar la variable $this en esta ocasión para la versión de Magento 2 se remplaza por $block, cualquier método definido en nuestras clases de bloque dinámico se podrá manda a llamar desde nuestra vista como se mostró en el ejemplo $block->getTitle(), ya que en el archivo de configuración Layout ya indicamos esta relación entre Layout, Templates y Block.

La siguiente imagen es una vista final de todo lo que acabamos de realizar con este módulo que contiene:

• Una clase de bloque dinámica
• Un Controlador principal
• Un ruteador frontName o nombre de URL definido
• La representación de una Vista Layout y su respectivo Template
• Y claro sin olvidar el archivo de configuración del modelo así como su script de registro del modelo