8 coisas que o desenvolvedor Magento deve saber sobre Magento 2

O Magento 2 está aí, e aqui no Brasil muita gente (e muita empresa) não está dando muita bola para ele. Os motivos são os mais diversos, e confesso que também demorei para começar a me render aos seus encantos.

Enfim ele chegou. E não adianta mais fugir. Vale a pena migrar? Isso é assunto pra outro post.
Hoje vamos falar nas principais mudanças e o que você precisa saber para sofrer menos com as mudanças.
Não adianta relutar e dar desculpas: o Magento 2 é realmente intimidador a primeira vista, usa novas tecnologias, novos conceitos, mas tudo isso para se manter como a melhor plataforma de e-commerce pela próxima década.
Para nossa sorte, muita coisa ainda é muito familiar ao Magento 1.

1. Separação de Módulos

Se você já desenvolve para Magento 1, sabe que os arquivos dos módulos ficam espalhados por tudo que é canto. Tem arquivos de template aqui, JS ali, css acolá, e por aí vai.

Não mais no M2. Code pools (app/code/core, community, local) também se foram. Tudo que for relacionado a um módulo, agora fica em uma única pasta: app/code/{vendor}/{module}.

A estrutura de pasta de um módulo é bem flexível agora, embora ainda existam algumas convenções como Blocks, Controllers, Helpers, Models, etc. Aqui algumas exceções:

• Configurações ainda estão em etc/.
• Scripts de setup ficam em arquivos especiais dentro de Setup/.
• Arquivos de template, layout XML, CSS, JS, etc. vão dentro de suas respectivas pastas dentro de view/.

2. Mage::Descanse em paz()

Esta é provavelmente a mudança mais difícil de ter sido implementada. Tudo que você estava acostumado(a) a acessar através da classe Mage foi dividido em bibliotecas separadas ou substituído.

Mage::registry, por exemplo, agora é \Magento\Framework\Registry.

Mage::getModel para carregar um objeto agora deve ser chamado via dependency injection (veja como funciona), o que força o desenvolvedor a ser mais explícito e cuidadoso sobre o que quer carregar.

Mage::log também foi substituído pelo Monolog, uma biblioteca bem conhecida para esses fins, e que também foi injetada em vários objetos. Veja a série de artigos sobre logs no Magento 2 que fiz.
Tudo que era Mage, junto com seus primos Varien, agora são encontrados em lib/internal/Magento/Framework (ou vendor/magento/framework). Nosso querido Varien_Object agora é \Magento\Framework\Object. Os setters e getters mágicos ainda estão lá, mesmo que as IDE’s não gostem deles – é melhor defini-los explicitamente.

3. Injeção de Dependência (DI)

(Injeção de Dependência?! Sério que alguém prefere assim?)

A maior mudança na arquitetura foi justamente a implementação de Dependency Injection. Você não consegue mais abrir um código-fonte sem vê-lo. Isso é ideal para testes unitários, separação de módulos, customizações, e gerenciamento de dependências de uma forma que nunca foi possível antes. Falo muito disso no curso de desenvolvimento para Magento 2.

De forma resumida, você define os objetos que quer acessar como argumentos do construtor de cada classe e armazena dele como membro da classe pra usar depois. O Magento vai automaticamente gerar os objetos certos quando sua classe for criada, e “injetar” eles no construtor pra você. Dependendo do tipo de classe, você pode querer definir os parâmetros diretamente, ou talvez devesse criar uma interface (classe abstrata) ou um factory (para criar models, collections, etc.).

4. Controllers

Os controllers agora são classes normais. São chamados ‘auto-loaded’, e podem ser estendidos como outra classe qualquer. Não é legal?

Nada de ‘IndexController’, ‘IndexAction’, e outras dores de cabeça com rewrites.
Além disso, você vai encontrar muito mais controllers do que antes. No Magento 1, você tinha um arquivo de controller contendo várias actions. Agora, aquele controller é chamado de path, e é uma pasta. Toda action tem seu próprio arquivo controller. e o Magento 2 chama o método “execute()” pra executar ele.

Veja a série sobre controllers no Magento 2 e entenda como funcionam. Comece por aqui.

<?php
namespace Magento\Catalog\Controller\Category;

class View extends \Magento\Framework\App\Action\Action
{

// ...

    public function execute()
    {
        if ($this->_request->getParam(\Magento\Framework\App\ActionInterface::PARAM_NAME_URL_ENCODED)) {
            return $this->resultRedirectFactory->create()->setUrl($this->_redirect->getRedirectUrl());
        }
        $category = $this->_initCategory();
        if ($category) {
// ...

5. Blocks

Esse parece besta, mas no Magento 1, os arquivos phtml eram executados dentro do escopo de suas classes (type). Ou seja, quando usávamos o $this, nos referenciávamos à classe do block, e você podia usar o $this para chamar qualquer membro da classe, seja ele publico, privado ou protected. Agora não mais.

Para acessar a classe do block a partir de um template no Magento 2, você precisará usar $block, e só poderá acessar métodos públicos. Existem algumas outras mudanças (e muitos novos padrões para códigos frontend), mas esse é o que mais se destaca.

6. Configuração

No Magento 1, a configuração de um módulo era bem flexível. Você tinha etc/config.xml, e se estivesse de bom humor, talvez criaria o adminhtml.xml.

No Magento 2, toda configuração de xml segue uma estrutura bem mais rígida e explícita, definida nos arquivos .xsd.

Seu módulo é definido em etc/module.xml. Eventos são definidos em etc/events.xml (ou etc/{area}/events.xml). Isso tudo é super bem explicado no Magento 2: O Curso.

Configurações são definidas em etc/adminhtml/system.xml, e as configurações padrão (antes em ) são definidas em etc/config.xml.

Existem muitos outros tipos de objetos de configuração, e você pode adicionar outros se precisar.

Seguindo a mesma linha, arquivos de layout XML também são estritos e a forma como são escritos e mesclados mudou bastante.

Cada handle de layout possuí seu próprio arquivo, mas o conceito pelo menos é o mesmo.

A parte boa dos XSD’s falaremos logo mais.

7. Vai ter que aprender a usar o terminal

O Magento 2 pegou pesado nas ferramentas de linha de comando, tanto para tarefas simples como outras mais pesadas. Agora é possível instalar e gerenciar módulos com o Composer.

Também existe o bin/magento, que tem dezenas de funcionalidades como: gerenciar caches, índices, trocar configurações da loja, compilar arquivos estáticos, limpar caches, e até mesmo instalar um magento do zero, incluindo (ou não) os arquivos de sample data (base de exemplo).

Existem ainda várias outras ferramentas de linha de comando, e bibliotecas composer que incluem pacotes para testes unitários, de performance, e muitas outras utilidades.

Veja também o n98-magerun para M2.

8. Complexidade

Já faz tempo que me rendi aos encantos do PhpStorm (e porque não, do magicento), mas ainda tem muito dev (se não a maioria) que prefere um editor de texto como o Sublime Text, VSCode, ou alguma variação de Notepad++.

No entanto, o Magento 2 pode ser um labirinto, sendo fácil se perder por lá. Novos padrões de código, dependency injection, e o strict XML baseado nos XSD’s tornam quase que obrigatórios o uso de uma IDE.

Se souber tirar proveito de uma IDE, ela te ajudará bastante no Magento 2, uma vez que você pode configurar os XSD’s do Magento na sua IDE, assim como os padrões de código, para auto-gerar DocBlocks, validar PSR’s, e rodar um php-cs-fixer toda vez que salvar um arquivo. Isso vale todo o tempo a mais que uma IDE pode tomar com seus reindexes.

Espero que você tenha gostado dessas dicas. Se você está começando com Magento 2, ou quer aperfeiçoar sua habilidade de desenvolvimento, considere se inscrever no Magento 2: O Curso.

Muita coisa também se encontra na documentação oficial e no Magento Stack Exchange, além é claro do nosso grupo no Facebook.

Este artigo foi baseado no post da ParadoxLabs, e traduzido parcialmente com autorização do autor.

• Sobre
• Últimos Posts

Ricardo Martins

É desenvolvedor web há 16 anos e um dos primeiros certificados pela Magento no Brasil. Instrutor de mais de 11 cursos Magento (os principais no magenteiro.com/cursos) com mais de 14 mil alunos de 105 países, é também criador do módulo PagSeguro Transparente, usado em mais de 12 mil lojas.

Últimos posts por Ricardo Martins (exibir todos)

• PagSeguro (PagBank) para Magento 1 recebe a Nova Geração - 9 de abril de 2024
• Recorrência no WooCommerce Sem Plugins Pagos - 28 de janeiro de 2024
• Chargeback. O que é, e como se livrar deles. - 19 de dezembro de 2023