As 7 áreas do Magento

O Magento separa alguns de seus componentes e códigos naquilo que chamamos de “áreas”. Essa separação ocorre em uma das primeiras partes da execução de código. Dependendo de onde o código ou requisição está sendo chamado, o Magento irá ler diferentes pastas.

Consequentemente, diferentes códigos e componentes serão executados e processados.

Por exemplo ao executar uma chamada às APIs REST do Magento, ao invés de ler códigos relacionados à área do frontend, apenas a área de webapi_rest será processada.

Quando criamos Plugins, arquivos de layout, de template e muitos outros arquivos e classes, parte do caminho onde este arquivo se encontra contém a área de execução. Por exemplo:

• app/code/Empresa/Modulo/etc/frontend/di.xml
• app/code/Empresa/Modulo/view/adminhtml/web/template/ui/exemplo.html
• app/code/Empresa/Modulo/etc/webapi_rest/di.xml
• app/code/Empresa/Modulo/view/base/layout/default.xml
• app/code/Empresa/Modulo/etc/crontab/di.xml

Tipos de áreas do Magento

Por padrão, existem 7 diferentes áreas:

• Admin (adminhtml): a porta de entrada desta área é o arquivo pub/index.php. Esta área inclui o código relacionado à área administrativa da loja. A pasta /app/design/adminhtml por exemplo, contém todos os componentes de design relacionados àquilo que vemos ao acessar o painel de administração de uma loja.
• Storefront (frontend): da mesma forma, o arquivo pub/index.php é a porta de entrada para requisições frontend. Esta área contém os arquivos usados quando um cliente acessa nossa loja e navega por ela. Note que geralmente nosso frontend faz chamadas às API’s do Magento, e estas requisições em especial são processadas em outra área.
• Basic (base): esta pasta ou área é usada como fallback. Ou seja, se um arquivo for solicitado em frontend ou adminhtml e não existir lá, o Magento tentará buscá-lo na pasta base. Arquivos de design que são usados em frontend e adminhtml geralmente são colocados aqui.
• Cron (crontab): no pub/cron.php (responsável pelas tarefas agendadas do Magento), a classe \Magento\Framework\App\Cron sempre carregará esta área.
• Web API REST (webapi_rest): assim como todas as outras API’s, a porta de entrada também é pub/index.php. Quando uma chamada é feita ao Controller da API Rest (geralmente /rest/V1) esta área é utilizada.
• GraphQL (graphql): área usada nas chamadas às APIs GraphQL do Magento
• Web API SOAP (webapi_soap): área usada nas chamadas à API SOAP (alguém ainda usaria isso?).

Como as áreas funcionam em conjunto com os módulos

Um módulo pode influenciar diversas áreas da loja. Por exemplo o módulo de catálogo (Magento_Catalog). Ele modifica páginas visíveis pelo usuário (frontend), oferece recursos para gerenciar produtos na área administrativa (adminhtml), e oferece suporte à API’s. Além de possuir tarefas que são executadas de tempos em tempos (crontab).

Lembre-se que:

• Módulos não devem depender de áreas definidas em outros módulos
• Desabilitar uma área não desabilita módulos que usam ou implementam mudanças nesta área
• Áreas são registradas no di.xml do framework Magento

Processamento da área

Como já vimos no Magento 2: O Curso, quando uma requisição é feita para o Magento, ele quebrará a URL em pelo menos 3 partes: frontName, pasta do controller, e classe do controller.

Ex: loja.com.br/customer/account/create

• frontName: customer
• pasta do controller: account
• classe do controller: create

O Magento usa o frontName para determinar a que tipo de área esta requisição pertence. Podemos ver isso em \Magento\Framework\App\Http::launch, um dos primeiros métodos a ser executado em todas as requisições do Magento que passam por pub/index.php.

public function launch()
{
    $areaCode = $this->_areaList->getCodeByFrontName($this->_request->getFrontName());
    $this->_state->setAreaCode($areaCode);
    #...

Note que no caso do crontab, o arquivo de entrada não é o pub/index.php, mas sim o pub/cron.php e a área a ser executada é definida de forma direta por ele em \Magento\Framework\App\Cron::launch.

Conclusão

Em muitos casos o Magento nos permite realizar uma implementação que afetará todas as áreas do sistema.

A injeção de dependência por exemplo, é feita pelo arquivo di.xml. Ele pode ser colocado diretamente dentro da pasta /etc/ de nosso módulo e ser lido pelo Magento em todas as requisições.

No entanto, se soubermos quais áreas temos à nossa disposição, e nos dermos ao trabalho de separar cada implementação em sua pasta correta, teremos um ganho de performance e organização. Afinal ficará muito mais fácil encontrar uma customização e entender que áreas nosso componente influencia em nossa loja.

Referência: Documentação Oficial (em Inglês)

• 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