Una de las cosas en las que he estado haciendo un esfuerzo mucho m\u00e1s concertado, probablemente m\u00e1s que nunca antes, es gestionar la separaci\u00f3n de preocupaciones entre las clases responsables de la interfaz con WordPress y las responsables de trabajar con el dominio del problema.<\/p>\n
Por ejemplo, supongamos que est\u00e1 trabajando en un complemento y se comunicar\u00e1 con una API de terceros. Adem\u00e1s, este complemento tambi\u00e9n ofrecer\u00e1 men\u00fas, tipos de publicaciones, taxonom\u00edas, etc. dentro del \u00e1rea de administraci\u00f3n de WordPress.<\/p>\n
Aqu\u00ed hay dos \u00e1reas de responsabilidad:<\/p>\n
Puede argumentar que es importante realizar pruebas unitarias en las \u00e1reas que se comunican con WordPress, pero tambi\u00e9n s\u00e9 que estas son API probadas y verdaderas que tienen su propio conjunto de pruebas.<\/p>\n
En su lugar, deber\u00edamos centrarnos en las pruebas unitarias y separar nuestra l\u00f3gica empresarial de WordPress.<\/p>\n
Pero ese no es el punto de esta publicaci\u00f3n. En cambio, se trata m\u00e1s de una forma de dise\u00f1ar potencialmente un proyecto cuando una parte de \u00e9l se conectar\u00e1 con WordPress.<\/p>\n
He hablado sobre la importancia y las ventajas de los espacios de nombres en publicaciones anteriores para no profundizar demasiado en esa discusi\u00f3n aqu\u00ed.<\/p>\n
En cambio, me interesa hablar sobre la organizaci\u00f3n de archivos a nivel de sistema de archivos y de espacio de nombres, para que est\u00e9n claramente separados en sus \u00e1reas de especializaci\u00f3n y para que podamos asegurarnos de que estamos, digamos, enfocando nuestras pruebas unitarias (y otras pruebas) en las \u00e1reas que son m\u00e1s cr\u00edticas.<\/p>\n
Me gusta asegurarme de que mi estructura de directorios y archivos refleje la de mis espacios de nombres. Claro, ayuda con la organizaci\u00f3n de archivos, pero tambi\u00e9n con una organizaci\u00f3n conceptual.<\/p>\n
Es decir, si voy a trabajar con metaboxes, entonces s\u00e9 que probablemente pueda encontrar los archivos de metaboxes en un directorio anidado con el directorio principal de WordPress<\/strong> y luego dentro de un subdirectorio Admin<\/strong> seguido de un directorio MetaBox<\/strong>.<\/p>\n Con ese fin, \u00bfc\u00f3mo se ver\u00eda un conjunto de clases dise\u00f1adas para trabajar con cajas meta si escribimos c\u00f3digo para ellas de manera reutilizable? Teniendo en cuenta lo que sabemos sobre los metaboxes, sabemos que probablemente necesitaremos lo siguiente:<\/p>\n Teniendo en cuenta los puntos anteriores, quiz\u00e1s la estructura del directorio se ver\u00eda as\u00ed:<\/p>\n<\/p>\n A continuaci\u00f3n, tenemos un c\u00f3digo que refleja esta estructura. Es decir, dentro de nuestro directorio de WordPress<\/strong>, tendr\u00edamos el subdirectorio Admin<\/strong> ya que el cuadro meta se muestra dentro del \u00e1rea de administraci\u00f3n de WordPress, y tendr\u00edamos el subdirectorio Ver<\/strong> que contendr\u00eda el archivo responsable de mostrar la informaci\u00f3n.<\/p>\n Esto nos deja con la necesidad de crear algunas clases como se indica arriba. Quiz\u00e1s la clase base abstracta se ver\u00eda as\u00ed:<\/a><\/strong><\/p>\n Luego, una implementaci\u00f3n concreta extender\u00eda la clase y se ver\u00eda as\u00ed:<\/a><\/strong><\/p>\n Y finalmente, la vista de la clase contendr\u00eda cualquier marca y c\u00f3digo de plantilla para representar la informaci\u00f3n<\/a><\/strong> :<\/p>\n Esto nos brinda exactamente lo que necesitamos de una manera bien organizada y reutilizable para trabajar con metaboxes. Tambi\u00e9n se puede repetir para elementos como men\u00fas, tipos de publicaciones, taxonom\u00edas, etc.<\/p>\n Pero yo divago.<\/p>\n Como mencion\u00e9 anteriormente en la publicaci\u00f3n, creo que las clases de pruebas unitarias que resuelven problemas exclusivos de nuestro espacio de problemas son importantes. Esto significa que necesitar\u00eda decirle a su archivo de configuraci\u00f3n de PHPUnit que excluya sus archivos centrados en WordPress.<\/p>\n La ventaja de lo que he expuesto anteriormente es que esto se vuelve trivialmente f\u00e1cil. En pocas palabras, puede agregar esto<\/a><\/strong> a su archivo phpunit.xml<\/strong> :<\/p>\n Esto le brinda la capacidad de concentrarse en escribir pruebas espec\u00edficamente para su espacio problem\u00e1tico mientras se asegura de que est\u00e1 escribiendo c\u00f3digo escalable, mantenible y reutilizable basado en WordPress.<\/p>\n Actualmente estoy escribiendo un libro electr\u00f3nico (junto con una variedad de otro contenido premium). Si est\u00e1s interesado, echa un vistazo a lo que obtienes<\/a>.<\/p>\n\n
<?php\n\nnamespace AcmeWordPressAdminMetaBox;\n\nabstract class AbstractMetaBox\n{\n protected $postType;\n\n public function __construct()\n {\n $this->postType = 'acme_post_type';\n }\n\n abstract public function render();\n abstract public function display();\n}\n<\/code><\/pre>\n<?php\n\nnamespace AcmeWordPressAdminMetaBox;\n\nclass AcmeMetaBox extends AbstractMetaBox\n{\n \/**\n * {@inheritdoc}\n *\/\n public function render()\n {\n add_meta_box(\n 'acme-product-image',\n 'Product Image',\n [$this, 'display'],\n $this->postType,\n 'side',\n 'default'\n );\n }\n\n \/**\n * {@inheritdoc}\n *\/\n public function display()\n {\n include_once plugin_dir_path(__FILE__).'Views\/acme-product-image.php';\n }\n}\n<\/code><\/pre>\n<div class=\"product-image-metabox\">\n <p>\n <img src=\"<?= esc_html(get_post_meta(get_the_ID(), 'product_image', true)); ?>\" alt=\"<?= esc_attr(get_the_title()); ?>\" \/>\n <input type=\"text\" value=\"<?= esc_html(get_post_meta(get_the_ID(), 'product_image', true)); ?>\" \/>\n <\/p>\n<\/div><\/code><\/pre>\nUna palabra sobre las pruebas unitarias (con PHPUnit)<\/h3>\n
<testsuites>\n <testsuite name=\"Plugin\">\n <directory>.\/tests<\/directory>\n <exclude>.\/tests\/phpunit<\/exclude>\n <exclude>.\/src\/WordPress<\/exclude>\n <\/testsuite>\n<\/testsuites><\/code><\/pre>\n