Magento 2: Basado en una historia real
•Descargar como PPTX, PDF•
2 recomendaciones•846 vistas
Este documento presenta una introducción a Magento 2. Explica los oradores y su experiencia, e incluye una sección sobre los primeros pasos en Magento 2 como documentación, capacitación y experiencia práctica. También detalla casos prácticos como la creación de un administrador de imágenes y la integración con un CMS externo a través de una capa de servicios.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (7)
Similar a Magento 2: Basado en una historia real
Similar a Magento 2: Basado en una historia real (20)
Último
Último (16)
Magento 2: Basado en una historia real
- 1. Magento 2 Basado en una historia real
- 2. ¿Quienes somos? Facundo Capua Technical Manager Nahuel Sanchez Front-End Technical Leader Nicolás Gándara Senior Back-End Developer
- 3. • Magento 2: ¿Y ahora? • Primeros pasos en Magento 2 • Casos prácticos • Conclusiones ¿Qué les vamos a contar?
- 5. Magento 2: ¿Y ahora?
- 8. Magento 2: Primeros pasos
- 9. Magento 2: Primeros pasos • Documentación oficial • Magento 2 Fundamentals (on demand) • Magento 2 Trained Solution Partner Program • Magento 2 Class Add on (presencial)
- 10. Magento 2: Primeros pasos Magento 2 Training Programs Fundamentals Courses Documentation Videos Books Real-world Experience +
- 11. Casos prácticos
- 12. Requerimiento Como cliente necesito administrar información sobre imágenes, para luego poder mostrarlas en un slider en la página principal. Estas contendrán la siguiente información: título, activo (si/no) y url de la imagen.
- 13. ABM Imágenes UIComponents UI Components ¿Con qué nos encontramos en el desarrollo del ABM? ¿Qué fue lo que más nos llamo la atención?
- 14. ABM Imágenes - UI components Principales componentes • Listing component. • Form component. Otros componentes. • Filter component. • Pagination component. Columns Components. y otros.. Principales componentes • Listing component. • Form component. Otros componentes. • Filter component. • Pagination component. Columns Components. y otros..
- 15. ABM Imágenes - Layout
- 16. ABM Imagenes - UI component - Listing Listing component argumentos • DataSource • Containers • Columns • Filtering • Pagination • y más…
- 17. ABM Imágenes - UI component - Listing Data Provider
- 18. ABM Imágenes - UI component - <Columns> Argumentos <column> • Tipo de dato • Orden • Alineación • Título • entre otras…
- 19. ABM Imagenes - UI component - <Filters> Distintos tipos de filtro • filterInput • filterRange • filterDate • filterSelect • entre otros…
- 20. ABM Imágenes - Demo
- 21. Requerimiento Como cliente necesito administrar información sobre imágenes, para luego poder mostrarlas en un slider en la página principal. Estas contendrán la siguiente información: título, activo (si/no) y url de la imagen. A su vez dichas imágenes tienen que poder ser accesibles y administrables desde un CMS externo.
- 22. CMS Externo ¿Qué nos provee Magento 2 para la manipulación de los datos de nuestras entidades? Al CMS externo no le interesa saber nada acerca de la lógica del negocio. El CMS externo necesita enviar y recibir datos sin necesidad de entender como estos son manipulados en Magento.
- 23. CMS Externo - Service Layer
- 24. CMS Externo - Service Contracts Interfaces de datos en el directorio /Api/Data Tres tipos de servicios • Interfaces de repositorio • Interfaces de administración • Interfaces de metadatos Interfaces de servicios en el espacio de nombres /API del módulo
- 25. CMS Externo - Service Contracts - Interfaces Getters / Setters
- 26. CMS Externo - Service Contracts - Interfaces
- 27. CMS Externo - Service Contracts - Implementaciones
- 28. CMS Externo - Service Contracts - Implementaciones
- 29. CMS Externo - Service Contracts - DI
- 30. CMS Externo - Service Layer
- 31. CMS Externo - Servicios REST
- 32. CMS Externo - Service Layer
- 33. CMS Externo - Servicios REST - Demo
- 34. CMS Externo - Service Layer
- 35. CMS Externo - Conclusiones • Service Layer: Nos permitió abstraer la lógica del manejo de las imágenes y hacerlas fácilmente disponibles para la capa de presentación. • WebApi Component: Facilidad y rapidez para exponer los servicios de ImageRepositoryInterface como REST.
- 36. Test Unitarios
- 38. Requerimiento “Como cliente quiero modificar la parte visual de mi sitio para adaptarla a mi marca.” • Al cliente le gusta toda o gran parte de la estructura por defecto. • Sólo quiere cambiar los colores por los utilizados por su marca, tipografías, y el logo.
- 39. 1. Crear un nuevo theme basado en magento/blank. 2. Aprovechar Magento UI Library ¿Cómo lo hacemos?
- 42. • Es una librería en LESS que agiliza el desarrollo del front-end de Magento. • Esta formada por mixins y variables que definen el aspecto visual de muchos elementos. • Como Bootstrap pero pensado para Magento. Magento UI Library
- 43. Magento UI Library actions-toolbar breadcrumbs buttons drop-downs forms icons layout loaders messages pagination popups ratings sections tabs accordions tables tooltips typography
- 45. Requerimiento “Como cliente quiero modificar la parte visual de mi sitio para adaptarla a mi marca.” • Al cliente le gusta toda o gran parte de la estructura por defecto. • Sólo quiere cambiar los colores para los utilizados por su marca, tipografías, y el logo.
- 50. Requerimiento “Como cliente quiero modificar el diseño aprovechando la llegada de la Navidad” • Agregar un fondo navideño detrás del logo. • Agregar una decoración navideña al slider de la página principal.
- 51. 1. Crear un nuevo theme basado en summa/fashion. 2. Extender el theme padre para las modificaciones visuales del header. 3. Modificar el front-end del módulo del slider. ¿Cómo lo hacemos?
- 55. Requerimiento Como administrador del sitio Summa Fashion necesito poder ofrecer descuentos diferenciados por producto y cliente ya que cuento con diferentes convenios.
- 57. Estrategia Price Calculation General Flow Lógica de Negocios
- 58. Implementación
- 59. Bonus Track
- 60. • PHPUnit, Selenium • Screenshot / Logs on failure • Entities: Fixture / Repository / Handler / Constraint • Test Cases: Injectable / Scenario Magento Testing Framework (MTF)
- 62. Conclusiones
- 63. • Desafiante • Facilitador • Estructurado • Homogéneo Conclusiones
- 64. GRACIAS
Notas del editor
- Somos Summa Solutions: - empresa líder en desarrollo de e-commerce en latinoamerica - parte del equipo que se está dedicando a Magento2 - Magento2 como desafio
- No detenerse, los puntos se explican más adelante.
- - Modern tech stack: Composer, ZF2, Sy2, RequireJS, jQuery, LESS Performance: FPC in core, indexes, varnish, production mode ACORTAR: Streamlined customizations: código desacoplado, service layer, decoupled code High code quality: Implementación consistente, test coverage, dependency injection, XSD ACORTAR: Easier installations & upgrades: herramienta de instalación, Semantic Versioning ACORTAR: Simplified external integration: API Layer mejorada, estructura modular
- Magento 2 está dividido en diferentes capas. Magento Framework <> Magento Modules ANOTACIÓN: Mejorar gráfico de arquitectura
- Seguimiento de los avances Desafío, stack tecnológico: Stack que no seguia la tendencia de la industria No subestimar el esfuerzo que iba a llevar
- Documentación oficial: Comparación con Magento1 Magento 2 Fundamentals: Buena experiencia de Magento1 / Opción FE y BE / Ejercicios de refuerzo propuestos Magento 2 Magento 2 Trained Solution Partner: Poner en práctica lo visto en el curso on demand Magento 2 Class Add On: 3 días intensivo / instructor para resolver las dudas
- Fundamentals es importante para entender las bases Real-world experience es indispensable para dominar la plataforma (no sólo Magento 2, sino cualquiera) Re implementar un sitio de Magento2, ahora lo encapsulamos Summa Fashion para mantener el anonimato del cliente.
- Luego de leer el requerimiento, se hará click y se focalizará en la primer oración del requerimiento. Como se dijo anteriormente, el primero de los temas trata acerca de ABM en el backend.
- Aca la idea es hablar acerca de los aspectos tecnicos que involucra la realizacion de un abm en magento 1, como lo conocemos. Luego una comparatiba con los cambios en magento 2, y haciendo foco en la introduccion de nuevos componentes(Containers, UI components).(Esto me intrude al tema pricipal) Si bien hay cambios en otros de los aspectos mencionados en Magetento 1, como por ejemplo los controlaros que blablabla…, nos parecio interesante mostrar estos nuevos elementos de magento 2.
- Entonces ¿Que son los UI Components?
- Para poder empezar a hablarles de los iu compoenentes,
- Bueno, como podemos ver el primer nodo que define el componente se denomina “listing”, dentro de este este tenemos la posibilidad de insertar varios tipos de componentes secundarios. El mas importante es el elemento denominado DataSource, este es obligatorio ya que es corazon de la configuracion (por asi decirlo). Lo mas importante a destacar es de las configuraciones de este es ek DataProvider que se le pasa como argumento,y el cual se puede ver que para nuestro ejemplo de imagenes el primer argumento que se le pasa es la clase con el nombre X. Que es esta clase? es una clase virtual, en realidad no existe,.. si vamos a nuestro di.xml podemos ver el tag <virtual type> se le indica que utilice otra en lugar de ella, en nuestro caso la otra es una collection de imagenes que se encuentra implementada dentro de la carpeta model, similar a como la conocemos en magento 1. A su vez el componente DataSource es conpartido por los otros componentes configurados en el listing, los cuales hace uso de este para en su logica de rendirazado.
- Bueno, como podemos ver el primer nodo que define el componente se denomina “listing”, dentro de este este tenemos la posibilidad de insertar varios tipos de componentes secundarios. El mas importante es el elemento denominado DataSource, este es obligatorio ya que es corazon de la configuracion (por asi decirlo). Lo mas importante a destacar es de las configuraciones de este es ek DataProvider que se le pasa como argumento,y el cual se puede ver que para nuestro ejemplo de imagenes el primer argumento que se le pasa es la clase con el nombre X. Que es esta clase? es una clase virtual, en realidad no existe,.. si vamos a nuestro di.xml podemos ver el tag <virtual type> se le indica que utilice otra en lugar de ella, en nuestro caso la otra es una collection de imagenes que se encuentra implementada dentro de la carpeta model, similar a como la conocemos en magento 1. A su vez el componente DataSource es conpartido por los otros componentes configurados en el listing, los cuales hace uso de este para en su logica de rendirazado.
- Luego de leer el requerimiento, se hará click y se focalizará en la primer oración del requerimiento. Como se dijo anteriormente, el primero de los temas trata acerca de ABM en el backend.
- Entonces, como dice la pregunta..¿Magento 2, que es los que nos brinda a nosotros como desarrolladores para hacernos la vida un poco más sencilla, flexible, extensible, modificable, escalable...arquitectonicamente hablando? El CMS no debe entender como estos datos son guardados, o como es la lógica para consumir datos sobre ciertas entidades, en este caso nuestras imagenes. Como cliente solo se necesita enviar y recibir datos, con un determinado acuerdo entre las partes involucradas, en este caso entre MAGENTO y alguna otra que a nosotros no nos interesa saber. Y es aquí en Magento 2, donde se introduce los que se denominan SERVICE CONTRACTS.
- Para hablar de lo que son los service contracts, tenemos que hablar de la arquitectura de magento….. En la imagen podemos ver algunas cosas conocidas y otras no tanto.. Esta nueva capa de servicios que se encuentra entre la de presentacion y la capa de logica de negocios nos brinda muchos beneficios a nivel arquitectonico… porque?? En un nivel un poco mas tecnico, el objetivo es relizar todos los llamados desde otros modulos atravez de la capa de servicios, es decir cuando hablo de todos me refiero a los controladores, bloques, helpers, etc. Que beneficios nos provee a nosotros como desarrolladores, y al cliente por supuesto?? hacernos la vida mas facil, sobre todo en priyectos muy grandes los cuales la cantidad de customizaciones pueden ser muchas. Entonces, entre otras cosas nos permite: Desde la capa de presentación, abstraer lógica de negocios que normalmente se encuentran en los bloques o templates. Nos asegura que toda la lógica de negocio se puede hacer fácilmente disponibles para aplicaciones externas como servicios web (en un ratito vamos a ver los facil que es). (Esto era un problema a veces en Magento 1 donde la lógica de código de servicios web incluido lógica duplicado de la capa de presentación, lo que causó problemas cuando extensiones en funcionamiento cambiado la interfaz de usuario, pero se perdió la API de servicios web, lo que resulta en un comportamiento incoherente.) Puede hacer más fácil la depuración - puntos de interrupción en un depurador es más fácil cuando se sabe que todas las llamadas fluirán a través. Hace que sea más fácil de sustituir la lógica de negocio - todas las llamadas se canalizan a través de una única API. En magento 1, puede pasar que otros módulos salten código de otro módulo en cualquier momento, por lo que es más difícil para una extensión de garantizar interceptó todas las llamadas correctamente. (Ver un ejemplito cotidiano) El uso de definiciones de interfaz hace que sea más sencillo de sustituir por completo la implementación de un servicio con una definición alternativa. (Una idea interesante aquí es tener un módulo que sólo contiene la definición de interfaz de servicio y tener otros módulos proporcionan implementaciones alternativas de la interfaz de servicio. Esto puede ser una exageración para cada capa de servicio del módulo, pero para las API clave como el envío esta podría ser una interesante idea.) http://alankent.me/2014/05/22/magento-2-service-layer/ Benefecios y mas Merchants might be reluctant to upgrade Magento because customized extensions that they have purchased might not be compatible with new versions of Magento. Also, Magento and third-party developers can find it difficult to track and report the dependencies that customized extensions have on other extensions. A service contract is a set of PHP interfaces that are defined for a module. A service contract includes data interfaces, which preserve data integrity, and service interfaces, which hide business logic details from service requestors such as controllers, web services, and other modules. Magento is a modular system. Service contracts define agreements between clients and implementations of services. For a client, a well-defined API it can rely on to be (relatively) stable across upgrades is great. But Magento also wants to allow other implementations to be slotted in as well, and service contracts help here too. All service contracts (that obey some simple rules) can be easily exposed as REST or SOAP with no additional PHP coding required. That opens up more external integration possibilities and more creativity in frontend design and technologies. It is also open to all extension developers.
- Para ser precicios esta nueva capa de servicios, los services contract, practicamente son un conjunto de interfaces que residen en Module/App directorios, las cuales nosotros como desarrolladores debemos definirlas.. Estas interfaces nos van a proveer accesos a la logica del negocio para poder ser llamadas desde la capa de presentacion, dentro de el espacio de nombres Api/Data, el cual va a contener las interfaces de acceso a las estructuras de datos o pasadas o retornadas a travez de las funciones definidas en las interfaces del directorio api. Como podemos en el slide esta nueva capa nos provee tres tipo de interfaces, nosotros solo vamos hacer hincapie solo en la primera ya que la que utilizamos para el desarrollo de nuestro ejemplo, pero no queriamos dejar de nombrarlas para que sepan que existen otras.. Interfaces de repositorio dan acceso a entidades de datos persistentes. En el caso de nuestro modulo, vammos a tener acceso a la informacion de las imagenes, otros casos de magento son las de los customer, estas incluyen al cliente, dirección, y el Grupo por ejemplo. Por lo tanto hay tres interfaces CustomerRepositoryInterface, AddressRepositoryInterface y GroupRepositoryInterface. ..
- Entonces, continuando con nuestro ejemplo, podemos ver en la imagen de la izquierda nuestro modulo con sus respectica estructura de directorios en la cual podemos ver la inclusion de la carpeta API, la cual contiene tanto la interfaz ImageRepositoryInterface, y dentro de data la interfaz de la entidad ImageInterface. Sobre la derecha podemos ver la la definicion del reposorio en donde podemos ver metodos comunes para cualquier tipo repositorio, getList al cual recibe como parametro un objeto del TIpo SearchCriteria(si bien no se hablo este probe la logica para las busquedas). Tambien pordemos ver el tipo load al cual se le pasa un id para poder obtener una determina entidad del tipo que implement ImageInterface, o por ultimo el metodo save para hacer el efectiva la persistencia de una nueva entidad o una entidad existente pero con sus datos modificados. Por ultimo la interfaz Image la cual nos probe metodos para acceder a informacion especifica de la imagen, como me habiamos dicho, titiulo, activo o no, fechas de creacion, entre otras.
- Entonces, continuando con nuestro ejemplo, podemos ver en la imagen de la izquierda nuestro modulo con sus respectica estructura de directorios en la cual podemos ver la inclusion de la carpeta API, la cual contiene tanto la interfaz ImageRepositoryInterface, y dentro de data la interfaz de la entidad ImageInterface. Sobre la derecha podemos ver la la definicion del reposorio en donde podemos ver metodos comunes para cualquier tipo repositorio, getList al cual recibe como parametro un objeto del TIpo SearchCriteria(si bien no se hablo este probe la logica para las busquedas). Tambien pordemos ver el tipo load al cual se le pasa un id para poder obtener una determina entidad del tipo que implement ImageInterface, o por ultimo el metodo save para hacer el efectiva la persistencia de una nueva entidad o una entidad existente pero con sus datos modificados. Por ultimo la interfaz Image la cual nos probe metodos para acceder a informacion especifica de la imagen, como me habiamos dicho, titiulo, activo o no, fechas de creacion, entre otras.
- Para hablar de lo que son los service contracts, tenemos que hablar de la arquitectura de magento….. En la imagen podemos ver algunas cosas conocidas y otras no tanto.. Esta nueva capa de servicios que se encuentra entre la de presentacion y la capa de logica de negocios nos brinda muchos beneficios a nivel arquitectonico… porque?? En un nivel un poco mas tecnico, el objetivo es relizar todos los llamados desde otros modulos atravez de la capa de servicios, es decir cuando hablo de todos me refiero a los controladores, bloques, helpers, etc. Que beneficios nos provee a nosotros como desarrolladores, y al cliente por supuesto?? hacernos la vida mas facil, sobre todo en priyectos muy grandes los cuales la cantidad de customizaciones pueden ser muchas. Entonces, entre otras cosas nos permite: Desde la capa de presentación, abstraer lógica de negocios que normalmente se encuentran en los bloques o templates. Nos asegura que toda la lógica de negocio se puede hacer fácilmente disponibles para aplicaciones externas como servicios web (en un ratito vamos a ver los facil que es). (Esto era un problema a veces en Magento 1 donde la lógica de código de servicios web incluido lógica duplicado de la capa de presentación, lo que causó problemas cuando extensiones en funcionamiento cambiado la interfaz de usuario, pero se perdió la API de servicios web, lo que resulta en un comportamiento incoherente.) Puede hacer más fácil la depuración - puntos de interrupción en un depurador es más fácil cuando se sabe que todas las llamadas fluirán a través. Hace que sea más fácil de sustituir la lógica de negocio - todas las llamadas se canalizan a través de una única API. En magento 1, puede pasar que otros módulos salten código de otro módulo en cualquier momento, por lo que es más difícil para una extensión de garantizar interceptó todas las llamadas correctamente. (Ver un ejemplito cotidiano) El uso de definiciones de interfaz hace que sea más sencillo de sustituir por completo la implementación de un servicio con una definición alternativa. (Una idea interesante aquí es tener un módulo que sólo contiene la definición de interfaz de servicio y tener otros módulos proporcionan implementaciones alternativas de la interfaz de servicio. Esto puede ser una exageración para cada capa de servicio del módulo, pero para las API clave como el envío esta podría ser una interesante idea.) http://alankent.me/2014/05/22/magento-2-service-layer/ Benefecios y mas Merchants might be reluctant to upgrade Magento because customized extensions that they have purchased might not be compatible with new versions of Magento. Also, Magento and third-party developers can find it difficult to track and report the dependencies that customized extensions have on other extensions. A service contract is a set of PHP interfaces that are defined for a module. A service contract includes data interfaces, which preserve data integrity, and service interfaces, which hide business logic details from service requestors such as controllers, web services, and other modules. Magento is a modular system. Service contracts define agreements between clients and implementations of services. For a client, a well-defined API it can rely on to be (relatively) stable across upgrades is great. But Magento also wants to allow other implementations to be slotted in as well, and service contracts help here too. All service contracts (that obey some simple rules) can be easily exposed as REST or SOAP with no additional PHP coding required. That opens up more external integration possibilities and more creativity in frontend design and technologies. It is also open to all extension developers.
- Por ultimo y no menos importante (para responder al requiermiento) el archivo de configuracion webapi.xml que podemos ver sobre la izquierda, este archivo sirve para indicar que url responde a que metodos de nuestro repositorio de imagenes, (aca es nombrar que metodo reponde a que url)
- Para hablar de lo que son los service contracts, tenemos que hablar de la arquitectura de magento….. En la imagen podemos ver algunas cosas conocidas y otras no tanto.. Esta nueva capa de servicios que se encuentra entre la de presentacion y la capa de logica de negocios nos brinda muchos beneficios a nivel arquitectonico… porque?? En un nivel un poco mas tecnico, el objetivo es relizar todos los llamados desde otros modulos atravez de la capa de servicios, es decir cuando hablo de todos me refiero a los controladores, bloques, helpers, etc. Que beneficios nos provee a nosotros como desarrolladores, y al cliente por supuesto?? hacernos la vida mas facil, sobre todo en priyectos muy grandes los cuales la cantidad de customizaciones pueden ser muchas. Entonces, entre otras cosas nos permite: Desde la capa de presentación, abstraer lógica de negocios que normalmente se encuentran en los bloques o templates. Nos asegura que toda la lógica de negocio se puede hacer fácilmente disponibles para aplicaciones externas como servicios web (en un ratito vamos a ver los facil que es). (Esto era un problema a veces en Magento 1 donde la lógica de código de servicios web incluido lógica duplicado de la capa de presentación, lo que causó problemas cuando extensiones en funcionamiento cambiado la interfaz de usuario, pero se perdió la API de servicios web, lo que resulta en un comportamiento incoherente.) Puede hacer más fácil la depuración - puntos de interrupción en un depurador es más fácil cuando se sabe que todas las llamadas fluirán a través. Hace que sea más fácil de sustituir la lógica de negocio - todas las llamadas se canalizan a través de una única API. En magento 1, puede pasar que otros módulos salten código de otro módulo en cualquier momento, por lo que es más difícil para una extensión de garantizar interceptó todas las llamadas correctamente. (Ver un ejemplito cotidiano) El uso de definiciones de interfaz hace que sea más sencillo de sustituir por completo la implementación de un servicio con una definición alternativa. (Una idea interesante aquí es tener un módulo que sólo contiene la definición de interfaz de servicio y tener otros módulos proporcionan implementaciones alternativas de la interfaz de servicio. Esto puede ser una exageración para cada capa de servicio del módulo, pero para las API clave como el envío esta podría ser una interesante idea.) http://alankent.me/2014/05/22/magento-2-service-layer/ Benefecios y mas Merchants might be reluctant to upgrade Magento because customized extensions that they have purchased might not be compatible with new versions of Magento. Also, Magento and third-party developers can find it difficult to track and report the dependencies that customized extensions have on other extensions. A service contract is a set of PHP interfaces that are defined for a module. A service contract includes data interfaces, which preserve data integrity, and service interfaces, which hide business logic details from service requestors such as controllers, web services, and other modules. Magento is a modular system. Service contracts define agreements between clients and implementations of services. For a client, a well-defined API it can rely on to be (relatively) stable across upgrades is great. But Magento also wants to allow other implementations to be slotted in as well, and service contracts help here too. All service contracts (that obey some simple rules) can be easily exposed as REST or SOAP with no additional PHP coding required. That opens up more external integration possibilities and more creativity in frontend design and technologies. It is also open to all extension developers.
- Video que muestra el cms externo en funcionamiento, consumiento y enviando datos a magento, y por ultimo la validacion en el abm de magento mostrando de las nuevas imagenes enviadas atravez de el cms externo. Luego de esto otro video que muestra como atravez de alguna herramienta de prueba para servicios REST(chrome) se obtienen y envian datos.
- Para hablar de lo que son los service contracts, tenemos que hablar de la arquitectura de magento….. En la imagen podemos ver algunas cosas conocidas y otras no tanto.. Esta nueva capa de servicios que se encuentra entre la de presentacion y la capa de logica de negocios nos brinda muchos beneficios a nivel arquitectonico… porque?? En un nivel un poco mas tecnico, el objetivo es relizar todos los llamados desde otros modulos atravez de la capa de servicios, es decir cuando hablo de todos me refiero a los controladores, bloques, helpers, etc. Que beneficios nos provee a nosotros como desarrolladores, y al cliente por supuesto?? hacernos la vida mas facil, sobre todo en priyectos muy grandes los cuales la cantidad de customizaciones pueden ser muchas. Entonces, entre otras cosas nos permite: Desde la capa de presentación, abstraer lógica de negocios que normalmente se encuentran en los bloques o templates. Nos asegura que toda la lógica de negocio se puede hacer fácilmente disponibles para aplicaciones externas como servicios web (en un ratito vamos a ver los facil que es). (Esto era un problema a veces en Magento 1 donde la lógica de código de servicios web incluido lógica duplicado de la capa de presentación, lo que causó problemas cuando extensiones en funcionamiento cambiado la interfaz de usuario, pero se perdió la API de servicios web, lo que resulta en un comportamiento incoherente.) Puede hacer más fácil la depuración - puntos de interrupción en un depurador es más fácil cuando se sabe que todas las llamadas fluirán a través. Hace que sea más fácil de sustituir la lógica de negocio - todas las llamadas se canalizan a través de una única API. En magento 1, puede pasar que otros módulos salten código de otro módulo en cualquier momento, por lo que es más difícil para una extensión de garantizar interceptó todas las llamadas correctamente. (Ver un ejemplito cotidiano) El uso de definiciones de interfaz hace que sea más sencillo de sustituir por completo la implementación de un servicio con una definición alternativa. (Una idea interesante aquí es tener un módulo que sólo contiene la definición de interfaz de servicio y tener otros módulos proporcionan implementaciones alternativas de la interfaz de servicio. Esto puede ser una exageración para cada capa de servicio del módulo, pero para las API clave como el envío esta podría ser una interesante idea.) http://alankent.me/2014/05/22/magento-2-service-layer/ Benefecios y mas Merchants might be reluctant to upgrade Magento because customized extensions that they have purchased might not be compatible with new versions of Magento. Also, Magento and third-party developers can find it difficult to track and report the dependencies that customized extensions have on other extensions. A service contract is a set of PHP interfaces that are defined for a module. A service contract includes data interfaces, which preserve data integrity, and service interfaces, which hide business logic details from service requestors such as controllers, web services, and other modules. Magento is a modular system. Service contracts define agreements between clients and implementations of services. For a client, a well-defined API it can rely on to be (relatively) stable across upgrades is great. But Magento also wants to allow other implementations to be slotted in as well, and service contracts help here too. All service contracts (that obey some simple rules) can be easily exposed as REST or SOAP with no additional PHP coding required. That opens up more external integration possibilities and more creativity in frontend design and technologies. It is also open to all extension developers.
- Para hablar de lo que son los service contracts, tenemos que hablar de la arquitectura de magento….. En la imagen podemos ver algunas cosas conocidas y otras no tanto.. Esta nueva capa de servicios que se encuentra entre la de presentacion y la capa de logica de negocios nos brinda muchos beneficios a nivel arquitectonico… porque?? En un nivel un poco mas tecnico, el objetivo es relizar todos los llamados desde otros modulos atravez de la capa de servicios, es decir cuando hablo de todos me refiero a los controladores, bloques, helpers, etc. Que beneficios nos provee a nosotros como desarrolladores, y al cliente por supuesto?? hacernos la vida mas facil, sobre todo en priyectos muy grandes los cuales la cantidad de customizaciones pueden ser muchas. Entonces, entre otras cosas nos permite: Desde la capa de presentación, abstraer lógica de negocios que normalmente se encuentran en los bloques o templates. Nos asegura que toda la lógica de negocio se puede hacer fácilmente disponibles para aplicaciones externas como servicios web (en un ratito vamos a ver los facil que es). (Esto era un problema a veces en Magento 1 donde la lógica de código de servicios web incluido lógica duplicado de la capa de presentación, lo que causó problemas cuando extensiones en funcionamiento cambiado la interfaz de usuario, pero se perdió la API de servicios web, lo que resulta en un comportamiento incoherente.) Puede hacer más fácil la depuración - puntos de interrupción en un depurador es más fácil cuando se sabe que todas las llamadas fluirán a través. Hace que sea más fácil de sustituir la lógica de negocio - todas las llamadas se canalizan a través de una única API. En magento 1, puede pasar que otros módulos salten código de otro módulo en cualquier momento, por lo que es más difícil para una extensión de garantizar interceptó todas las llamadas correctamente. (Ver un ejemplito cotidiano) El uso de definiciones de interfaz hace que sea más sencillo de sustituir por completo la implementación de un servicio con una definición alternativa. (Una idea interesante aquí es tener un módulo que sólo contiene la definición de interfaz de servicio y tener otros módulos proporcionan implementaciones alternativas de la interfaz de servicio. Esto puede ser una exageración para cada capa de servicio del módulo, pero para las API clave como el envío esta podría ser una interesante idea.) http://alankent.me/2014/05/22/magento-2-service-layer/ Benefecios y mas Merchants might be reluctant to upgrade Magento because customized extensions that they have purchased might not be compatible with new versions of Magento. Also, Magento and third-party developers can find it difficult to track and report the dependencies that customized extensions have on other extensions. A service contract is a set of PHP interfaces that are defined for a module. A service contract includes data interfaces, which preserve data integrity, and service interfaces, which hide business logic details from service requestors such as controllers, web services, and other modules. Magento is a modular system. Service contracts define agreements between clients and implementations of services. For a client, a well-defined API it can rely on to be (relatively) stable across upgrades is great. But Magento also wants to allow other implementations to be slotted in as well, and service contracts help here too. All service contracts (that obey some simple rules) can be easily exposed as REST or SOAP with no additional PHP coding required. That opens up more external integration possibilities and more creativity in frontend design and technologies. It is also open to all extension developers.
- Prototype en el core desde el comienzo. SASS/Compass y jQuery recién en 1.14/1.9 dentro del package RWD LESS en reemplazo de SASS RequireJS para la carga de JS. Grunt para agilizar la etapa de desarrollo con compilación de LESS y LiveLoad.
- - Poco trabajo en la parte de modificación de estructuras, en los templates. Mucho trabajo en los estilos.
- No detenerse, los puntos se explican más adelante.
- ¿Qué es magento/blank? ¿hay otros themes? ¿cambio algo el theme inheritance comparado con Magento 1?
- ¿Qué es magento/blank? ¿hay otros themes? ¿cambio algo el theme inheritance comparado con Magento 1? Presentar summa/fashion.
- ¿Qué es? Una librería en LESS para agilizar el desarrollo de Magento. ¿Cómo está hecha? Mixins y variables. ¿Para que sirve? Permite modificar el look and feel del sitio de forma rápida. Compararlo con Bootstrap.
- Algunas de las cosas que permite customizar. Mencionar el comportamiento de la empresa de ofrecer diseños basados en la estructura de Magento.
- Mostrar rápidamente dónde se encuentran las cosas.
- - Poco trabajo en la parte de modificación de estructuras, en los templates. Mucho trabajo en los estilos.
- Creamos la carpeta del modulo Magento_Theme en nuestro theme summa/fashion. Nos traemos el default.xml por defecto de dicho módulo con el fin de editar el ancho y alto de la imagen Y agregamos el logo.png Retomar Magento UI Library con el _theme.less (colores, tipografías)
- Hacer hincapié en que sólo se editan variables, no hay CSS/LESS propiamente dicho (corchetes), son 30 lineas contando comentarios. Repasar que elementos se están alterando.
- Mostrar el cambio, repitiendo que sólo fueron 30 variables, se compiló y listo.
- Mostrar el cambio, repitiendo que sólo fueron 30 variables, se compiló y listo.
- - Recordar que Magento UI Library no es la solución para todos
- Especificar que estamos contentos con la estructura de summa/fashion, con las modificaciones implementadas por Magento UI Library, y que los cambios son menores sobre la base de lo existente. No vamos a detenernos en el primer punto.
- _extend.less, ¿cómo funciona?
- Hacemos referencia al modulo. _module.less, ¿qué es?
- Mostrar el cambio desde magento/blank, pasando por summa/fashion hasta summa/christmas
- DESTACAR: Cada cliente puede tener un descuento distinto por producto. No sirve el customer group. Posteriormente se piensa e una etapa B2B, donde este sería el escenario.
- - Agregar tabla de relación - La tabla se llena con un cron
- Nuevo flujo de cálculo de precios Mucho más maduro que Magento1
- 2 métodos claves: extractAdjustment / applyAdjustment Hacer que entre bien el signature, dejar el if completo, el query no es necesario
- MTF: Framework de Magento para realizar test funcionales PHPUnit / Selenium Fixture / Repository / Handlers Fixture: Listado de propiedades de la entidad a probar. Utilizado para probar un conjunto de test o como una pre condición. Repository: Información pre definida para un Fixture Handlers: Setear pre condiciones / preparar el entorno para ciertos test 3 tipos: curl, ui, webapi
- Desafiante: Terreno no explorado / Stack actualizado —> Cómo lo hace Magento2? Lo estábamos esperando Facilitador: En poco tiempo de desarrollo, hemos podido lograr bastante / MTF Estructurado: Tiene una buena estructura, y una una vez entendida es fácil navegar el código Homogeneos: Mantiene la coherencia y estructura en los diferentes módulos Diferencia entre “Magento way” y Magento 2 con standards de la industria.