¿Eres un desarrollador de Magento que aún no se ha sumergido en Magento 2? No tener miedo,
Bueno … tal vez no. Aprender Magento es una tarea pesada, después de todo, y esto sigue siendo cierto para la versión 2 de la plataforma. Unos cientos de palabras no te ayudarán a ponerte en marcha, obviamente. Sin embargo, si eres como yo, no saber por dónde empezar puede ser lo más intimidante de bucear. Por lo tanto, el objetivo real de este artículo es brindarte una visión general de las diferencias más significativas con Magento 1 que encontrarás. encuentro.
Cuando se moje los pies en la nueva plataforma, se sorprenderá gratamente al descubrir qué tan similar es el código línea por línea que realmente escribe. Por lo tanto, un poco de información sobre algunos conceptos arquitectónicos importantes contribuirá en gran medida a suavizar su transición al gurú de Magento 2.
Y antes de comenzar realmente, si aún no lo sabe, Magento 2 tiene una creciente colección de temas de documentación para entrar en detalles más precisos.
- ¿Vale la pena aprender italiano para la ópera?
- Cómo aprender más sobre el mercado de capitales para poder negociar FX
- ¿Qué debo aprender cuando me enfrento a un mal momento que pueda ser útil para mi vida?
- Cómo hacer que el aprendizaje de idiomas sea divertido y que sea parte de tu vida diaria
- ¿Cómo aprendió Sven Skoog a escribir tan bien?
Estructura del modulo
Si aún no está familiarizado con Composer, el administrador de dependencias de PHP que es muy popular, ahora es el momento de hacerlo, ya que el software es parte integral de la estructura de Magento 2. En lugar de una base de código de un solo núcleo, Magento es ahora una colección de Componentes individuales instalados a través de Composer. Esto se aplica a bibliotecas de terceros y módulos / temas centrales de Magento (es decir, paquetes) por igual. Las dependencias de paquetes se han formalizado de modo que cualquier “versión” particular de Magento se pueda expresar realmente en términos de las versiones de estos componentes y sus dependencias.
Si eres un desarrollador de extensiones de Magento distribuibles, también estarás creando paquetes de Composer. Sin embargo, en una nota más amplia, el tipo de encapsulación requerido para tales componentes autocontenidos se ve facilitado por un cambio en la estructura de Magento que seguramente hará la vida más fácil si su código es una extensión del mercado o simplemente una personalización local: todos los archivos relacionados con un módulo ahora reside en un solo directorio. Mientras que en los archivos PHP de Magento 1, el diseño XML, las plantillas y los activos estáticos estaban dispersos en diferentes ubicaciones, ahora todos los archivos para una sola característica viven juntos. El directorio de nivel superior de un módulo contiene los subdirectorios familiares de Bloque, Modelo, etc. (o, en realidad, cualquier subdirectorio en el que desea ubicar sus clases), junto con un subdirectorio de vista. Dentro de view / adminhtml o view / frontend hay directorios de diseño y plantillas, y un directorio web que contiene los activos estáticos del módulo como JavaScript y CSS.
EL DIRECTORIO PUB Y LA GENERACIÓN DE CÓDIGOS
El concepto de archivos de activos estáticos que viven en numerosos lugares, y las preguntas que esto plantea, son el segmento perfecto en el siguiente tema importante. La generación y el despliegue automatizados de código desempeñan un gran papel en Magento 2, y estos pueden entenderse parcialmente con una mirada al directorio del pub. Si bien es posible usar el directorio raíz de su instalación de Magento como su raíz web en los entornos de desarrollo, la raíz web necesaria en producción es el nuevo directorio de pub que se distingue de todo el código de la aplicación y contiene solo lo que Magento pone allí (incluido el punto de entrada principal de la aplicación). , archivos multimedia y de vista estática). Dado que el código del sitio ahora vive fuera de esta raíz web designada, el control de acceso es más rígido y predecible, y el nuevo proceso de implementación / compilación hace posible la encapsulación de módulos mencionada anteriormente:
La implementación del archivo de vista estática materializa todos los activos estáticos necesarios desde su origen en el código de la aplicación al directorio de publicación accesible en la web. Este proceso de implementación ocurre automáticamente en el modo de desarrollo pero requiere una acción explícita en la producción. Esta implementación automática de activos es lo que permite que todos los códigos JS / CSS vivan en su módulo apropiado, pero que estén disponibles en una ubicación centralizada.
La generación de código no implica el directorio del pub, pero está estrechamente relacionado con el concepto de implementación. Magento ahora genera ciertos tipos de clases de PHP y facilita una personalización más granular y discreta de lo que ha sido posible en el pasado.
INYECCIÓN DE DEPENDENCIA
La inyección de dependencia en Magento es un tema enorme, por lo que lo cubriré solo en los términos más amplios aquí. Magento 1 tenía sus métodos de fábrica que facilitaban las anulaciones de clase, como Mage :: getModel y Mage :: helper. Esto se reemplaza en Magento 2 por un enfoque más estructurado por el cual todos los tipos externos se inyectan como parámetros en el constructor de una clase de la siguiente manera:
Ejemplo.php
Ejemplo de clase
{
solicitud protegida de $;
protegido $ customerAccountManagement;
función pública __construida (
\ Magento \ Framework \ App \ Request \ Http $ request,
\ Magento \ Customer \ Api \ AccountManagementInterface $ customerAccountManagement
) {
$ this-> request = $ request;
$ this-> customerAccountManagement = $ customerAccountManagement;
}
}
Ejemplo.php
Ejemplo de clase
{
solicitud protegida de $;
protegido $ customerAccountManagement;
función pública __construida (
\ Magento \ Framework \ App \ Request \ Http $ request,
\ Magento \ Customer \ Api \ AccountManagementInterface $ customerAccountManagement
) {
$ this-> request = $ request;
$ this-> customerAccountManagement = $ customerAccountManagement;
}
}
Los tipos a los que se hace referencia de esta manera son automáticamente instanciados y pasados por el Administrador de objetos de Magento. Esto facilita el uso de nombres de clase reales y espacios de nombres de PHP en lugar de ensuciar el código con métodos de fábrica propietarios, crea un código más organizado al centralizar las referencias a las dependencias y permite un enfoque más flexible para anular las clases. Observe en el código anterior que una dependencia solo hace referencia a una interfaz, no a una clase completa. Las interfaces son un gran punto de énfasis en Magento 2, y las preferencias de dependencia definidas en un archivo de configuración especial, di.xml, especifican la mejor implementación predeterminada de dicha interfaz. Esta configuración DI es lo que los módulos de terceros utilizan para cambiar la preferencia de una interfaz predeterminada o una clase completa, ya sea globalmente (el equivalente a la reescritura de clases de Magento 1) o para contextos específicos (posible gracias a la centralización en los constructores). Las clases externas obtenidas a través de la inyección del constructor son instancias compartidas (es decir, un patrón “singleton”) y se denominan “inyectables”.
PLUG-INS
Como se mencionó anteriormente, las reescrituras de la clase Magento 1 encuentran su análogo en la capacidad de especificar las preferencias de inyección de dependencia. También mencioné que las técnicas de personalización más discretas son posibles gracias a la generación de código de M2, y los complementos son el ejemplo más significativo de esto. Los complementos le permiten alterar o extender métodos específicos en lugar de tener que reemplazar clases enteras.
Al igual que las preferencias, los complementos se definen en los archivos di.xml y tienen implementaciones específicas de “antes”, “después” y “alrededor”, respectivamente, lo que le permite modificar la entrada de un método original, operar más en su salida, o Rodéalo con tu propia lógica. Lo mejor de todo es que se pueden definir múltiples complementos en un solo método, lo que mejora enormemente la compatibilidad entre las extensiones que operan en la misma área del sistema. La generación de código de M2 y el Administrador de objetos se encargan de ejecutar las llamadas a los métodos de manera correcta y de entregarlos a los complementos según sea necesario. A continuación se muestra un ejemplo nativo de la definición e implementación de un complemento:
di.xml
StoreGroup.php
clase Grupo de tienda
{
función pública en torno a guardar (
\ Magento \ Framework \ Model \ ResourceModel \ Db \ AbstractDb $ subject,
\ Closure $ proceder,
\ Magento \ Framework \ Model \ AbstractModel $ group
) {
$ needInvalidating = $ this-> validate ($ group);
$ objectResource = $ proceder ($ group);
if ($ needInvalidating) {
$ this-> indexerRegistry-> get (\ Magento \ Catalog \ Model \ Indexer \ Category \ Product :: INDEXER_ID) -> invalidate ();
}
devuelve $ objectResource;
}
}
di.xml
StoreGroup.php
clase Grupo de tienda
{
función pública en torno a guardar (
\ Magento \ Framework \ Model \ ResourceModel \ Db \ AbstractDb $ subject,
\ Closure $ proceder,
\ Magento \ Framework \ Model \ AbstractModel $ group
) {
$ needInvalidating = $ this-> validate ($ group);
$ objectResource = $ proceder ($ group);
if ($ needInvalidating) {
$ this-> indexerRegistry-> get (\ Magento \ Catalog \ Model \ Indexer \ Category \ Product :: INDEXER_ID) -> invalidate ();
}
devuelve $ objectResource;
}
}
SUERTE
Sobre el tema de la inyección de dependencia, es posible que haya notado una omisión significativa. Los “inyectables”, como objetos de instancia compartidos, son realmente el equivalente de la técnica de fábrica Mage :: getSingleton de M1. Entonces, ¿cuál es el equivalente del método de fábrica de Mage :: getModel para obtener instancias de objetos únicos (es decir, “no inyectables” en el lenguaje M2)? Dichos objetos se crean instancias usando clases inyectables que están dedicadas al propósito: fábricas. Observe el siguiente uso de una clase de fábrica para crear una instancia de un modelo:
Ejemplo.php
Ejemplo de clase
{
protegido $ customerFactory;
función pública __construida (
\ Magento \ Customer \ Model \ CustomerFactory $ customerFactory
)
{
$ this-> customerFactory = $ customerFactory;
}
función pública getCustomer ($ email)
{
devuelve $ this-> customerFactory-> create () -> loadByEmail ($ email);
}
}
Ejemplo.php
Ejemplo de clase
{
protegido $ customerFactory;
función pública __construida (
\ Magento \ Customer \ Model \ CustomerFactory $ customerFactory
)
{
$ this-> customerFactory = $ customerFactory;
}
función pública getCustomer ($ email)
{
devuelve $ this-> customerFactory-> create () -> loadByEmail ($ email);
}
}
Su primera reacción a lo anterior podría ser pensar que definir y mantener una clase solo para manejar la creación de instancias de otra parece engorroso. En este sentido, los beneficios de la generación de código de M2 vienen al rescate nuevamente, porque las clases de fábrica en realidad no necesitan ser definidas en absoluto. Son creados automáticamente por Magento cuando se encuentra una referencia a dicha fábrica. El enfoque específico de la clase significa que puede definirlos explícitamente; sin embargo, si es necesario, puede personalizar fácilmente la técnica de fábrica para cualquier clase en particular.
LA CAPA DE SERVICIO
Al igual que la inyección de dependencia, la capa de servicio vale una serie completa de artículos por sí sola (consulte la documentación básica sobre contratos de servicio y patrones de diseño), pero el concepto básico se puede comprender con una pequeña explicación. Considere que uno de los principales desafíos para la personalización en Magento 1 era que el código se basaba casi con certeza en hacer referencia a los detalles específicos de la implementación de las clases principales de Magento, y que los cambios importantes en este código central (como las alteraciones de los parámetros o la lógica del método) podrían generar un código personalizado inoperable. La capa de servicio M2 alivia este problema al introducir una capa entre la lógica de negocios principal de un módulo y cualquier código externo que haga referencia a los componentes de ese módulo. Los “contratos de servicio” toman la forma de interfaces que definen rígidamente las entidades y las formas prescritas para que el código externo interactúe con ellas; estas interfaces y las clases que las implementan desde la capa de servicio.
Como ejemplo, consideremos la entidad cliente principal. Magento \ Customer \ Model \ Customer es el modelo para una entidad de cliente, y esta clase tiene modelos de recursos y recopilación correspondientes que cumplen el mismo propósito que sus contrapartes M1. Sin embargo, en lugar de hacer referencia a estas clases directamente, los módulos externos deben utilizar una clase de controlador de tráfico llamada Magento \ Customer \ Model \ ResourceModel \ CustomerRepository para obtener y manipular instancias de Magento \ Customer \ Model \ Data \ Customer. Ambas clases implementan interfaces de contrato de servicio, y mientras usan los datos típicos y los modelos de recopilación bajo el capó, los métodos expuestos en las interfaces hacen que esta implementación sea invisible y definan explícitamente los detalles en los que puede confiar el código externo. La lógica de los modelos y las colecciones puede cambiar en cualquier grado en el futuro, pero los detalles de los contratos de servicio seguirán siendo los mismos, preservando la compatibilidad de los módulos personalizados.
Las interfaces de contrato de servicio se encuentran en el subdirectorio API de un módulo. Si está produciendo un código distribuible, le recomendamos encarecidamente que cree contratos de servicio y clases para que sus propias entidades mantengan la compatibilidad futura con el código de otros.
PAGINA CACHE
En Magento 1, el caché de página completa era una característica de mejora del rendimiento disponible exclusivamente en Enterprise, y acomodarla en sus características personalizadas no era exactamente el tema de desarrollo más trivial. En M2, el almacenamiento en caché de página completa es una característica de Community y Enterprise, que vive en el módulo Magento_PageCache, y sus implicaciones para los desarrolladores son mucho más sencillas.
El desafío central del almacenamiento en caché de la página completa son las áreas de una página web cuyo contenido no puede ser universal para todos los visitantes y páginas vistas. M1 se enfocó en ensamblar contenido para dichas áreas como parte de la presentación de la salida HTML final, mientras que M2 adopta un enfoque diferente, y cada vez más popular. En primer lugar, los bloques de páginas que deben separarse del contenido del caché principal se definen de manera más sólida como “datos privados”: contenido que depende de la información de la sesión del visitante. En segundo lugar, dichos bloques se anonimizan para todos los visitantes en la representación inicial de la página, y los datos privados se cargan a través de una solicitud Ajax después de que se entrega el contenido de la página principal. Por lo tanto, el cuerpo principal de una página se almacena en caché y se entrega de la forma más rápida posible, con un contenido menos esencial y específico para el visitante que se materializa de forma asíncrona.
En términos de las implicaciones para los desarrolladores, acomodar el caché de la página es casi increíblemente simple en comparación con M1. Marcar un bloque como información privada es tan simple como establecer una sola propiedad, y Magento se encarga del resto:
ExampleBlock.php
clase ExampleBlock
{
función pública __construir ()
{
padre :: __ construir ();
$ this -> _ isScopePrivate = true;
}
}
ExampleBlock.php
clase ExampleBlock
{
función pública __construir ()
{
padre :: __ construir ();
$ this -> _ isScopePrivate = true;
}
}
Compilación de CSS
Desde la revisión de respuesta a su tema, la compilación de CSS en forma de SASS / Compass ha sido parte de Magento 1. La herramienta elegida en Magento 2 es MENOS, lo que aporta casi la misma capacidad, incluidas las variables de CSS, combinaciones para Estilos repetibles, organización de múltiples archivos con incluye, y mucho más.
Cubrir los aspectos específicos de LESS en M2 está fuera del alcance de este artículo, pero un concepto importante a comprender es cómo el desarrollador de M2 se ocupa de la compilación de CSS (o, para ser más precisos, no lo hace). En el tema de respuesta de M1, la compilación fue un proceso completamente invisible para la aplicación Magento; el desarrollador fue responsable de compilar el código fuente en los archivos CSS finales que luego se incluyeron explícitamente a través del diseño, como siempre se ha hecho. En M2, la magia de compilación de CSS se realiza en el nivel de la aplicación como parte del proceso de implementación de archivos estáticos mencionado anteriormente. Simplemente asegúrese de que los archivos de origen MENOS estén incluidos en las ubicaciones apropiadas, y Magento se ocupará del resto. (Vale la pena señalar que aún es ventajoso manejar la compilación de manera diferente durante el desarrollo, pero el punto es que el proceso está muy integrado en el núcleo de la aplicación).
Cualquier archivo de origen con prefijo de guión bajo colocado en el directorio view / {area} / web / css / source de un módulo o el directorio web / css / source de un tema se compilará en los estilos principales, con solo una instancia de un el nombre único se carga en todo el sitio, dependiendo de un orden de prioridad (lo que permite la anulación de parciales específicos). Además de esto, el nombre mágico _module.less y _widgets.less (para módulos) y _extend.less (para temas) permiten que los estilos sean acumulativos en lugar de anular directamente los parciales con nombres idénticos de otras fuentes.
JAVASCRIPT INCLUSION Y REQUIREJS
Magento 2 ha revisado su técnica para incluir JavaScript desde un enfoque tradicional que requiere explícitamente cada archivo JS con etiquetas a un método de “inclusión según sea necesario” que utiliza principalmente RequireJS. (Consulte esta página para obtener información sobre RequireJS en Magento). RequireJS es una herramienta robusta con su propia documentación, pero lo importante es comprender que permite encapsular JavaScript en recintos que declaran dependencias, de las que RequireJS gestiona la carga. Esto garantiza que los componentes de JavaScript se carguen solo cuando sea necesario y en el orden necesario.
El proceso casi podría considerarse una versión JS de inyección de dependencia, y hay varias formas de hacerlo en Magento. Aquí hay un ejemplo simple, que requiere el componente “mage / url” como una dependencia del código dentro del gabinete, pasando la clase devuelta por ese archivo como el parámetro de la función:
example.phtml
exigir([
‘mago / url’
], función (url) {
return url.setBaseUrl (‘http://www.mydifferentdomain.com’);
})
example.phtml
exigir([
‘mago / url’
], función (url) {
return url.setBaseUrl (‘http://www.mydifferentdomain.com’);
})
Las otras dos formas introducidas por Magento tratan con llamadas de alcance inmediato para los complementos de jQuery a selectores específicos y se pueden estudiar en la página de documentación de Magento. La definición precisa de la ubicación de los componentes nombrados se configura en un archivo por módulo llamado requirejs-config.js, y al igual que la inyección de dependencias, esta configuración permite la fácil extensión y reemplazo de componentes al reemplazar su definición con la suya.
COMPONENTES DE JAVASCRIPT
Un desarrollador que tenga mucho JavaScript tendrá que familiarizarse no solo con las técnicas para incluir el código JS, sino también con algunos de los enfoques poderosamente sistematizados que Magento lleva a su propio JavaScript. En primer lugar, vale la pena señalar que M2 hace un uso intensivo de los widgets de jQuery, tanto de la biblioteca de jQuery UI como de sus propios widgets personalizados. Cuando esté desarrollando interfaces pesadas de JS, también valdrá la pena el esfuerzo de utilizar este patrón en su propio código.
Un tema más complejo es la clase JS uiComponent (distinta de la biblioteca de Componentes de UI de M2) y la forma en que el diseño, JS y las plantillas estáticas pueden funcionar juntas. En este paradigma, los componentes JS que extienden uiComponent se pueden inicializar, y la configuración se puede pasar a ellos, a través del diseño XML. Entre esta configuración puede estar la definición de una ruta de plantilla estática utilizada para representar el componente, que se carga a través de Ajax sin la participación de PHP, y que contiene la sintaxis de Knockout para acceder dinámicamente a las propiedades y métodos expuestos en el componente JS. Obtener un control de este patrón en particular llevará un estudio del uso del núcleo de Magento y las capacidades de Knockout, pero aquí está el fragmento más simple de un ejemplo:
default.xml
Magento_Checkout / js / view / minicart
Magento_Checkout / minicart / content
default.xml
Magento_Checkout / js / view / minicart
Magento_Checkout / minicart / content
Cómo encaja lo anterior en la estructura de diseño y cómo su bloque principal inicializa dichos componentes está más allá de lo que puedo cubrir en un espacio tan limitado. Sin embargo, sepa que lo anterior define la ruta al archivo JS que representa este componente (minicart.js, que contiene una clase que extiende uiComponent) y un archivo de plantilla estática cargado directamente desde el servidor (content.html), que contiene referencias de código Knockout. lógica desde minicart.js.
Hay una gran cantidad de otros cambios arquitectónicos más pequeños en Magento 2 que podrían mencionarse, y usted se familiarizará con ellos a medida que sus pequeños emprendimientos en la nueva plataforma se vuelvan más grandes. Sin embargo, para el desarrollador que busca un lugar para comenzar, los temas anteriores representan algunas de las mejores maneras en que puede pasar su tiempo de entrenamiento de Magento 2. Empiece a familiarizarse con estos conceptos, y de seguro comenzará a ver a M2 como un amigo cálido en lugar de un extraño siniestro.