Certificação Magento – Front Controller

Neste artigo vamos dar uma introdução ao Front Controller, que é a classe do Magento que manipula toda a lógica, junta blocos e objetos e o renderiza e captura seus requests e responses.

magento-front-imagem-01

Vamos dar um exemplo se baseando no módulo que desenvolvi que cria um cadastro de ranges de CEP para o lojista poder escolher onde entregar fazendo com que o usuário digite seu CEP antes da compra, possibilitando ou impedindo a mesma.

Vamos rever alguns conceitos abordados em 2 posts anteriores quando discutimos.

magento-front-imagem-02

Pré-artigo

Antes de abordarmos FrontController vamos dar uma repassada em dois artigos anteriores:

URL’s no Magento

Módulos Magento – Parte 1

Depois de lido vamos dar uma clareada em como funciona o carregamento de uma página no Magento

Tudo começa na URL:

www.objectiveit.com.br/cep/busca/editar

O nome da empresa que desenvolveu nunca vai na URL.

O primeiro nome após a URL principal é o nome do módulo no meu caso o nome do desenvolvedor é Bobby e o nome do módulo é Cep (lembrando que se Bobby criar outros módulos eles estarão em pastas no mesmo nível da pasta Cep). Por isso procure dar um nome bem simples e sugestivo para seu módulo que estará sempre na URL enquanto ele for requisitado.

Após vem o nome do Controller, todos estão na pasta controller seguidos da palavra controller. Ex: BuscaController.php e o nome da classe é Bobby_Cep_BuscaController, é essa classe e todos os controllers no Magento que herdam o FrontController do Magento: Mage_Core_Controller_Front_Action.

Pronto ao digitar esta URL a primeira coisa que o Magento irá fazer é buscar este controller onde terá a maior parte da lógica da página, quando mais lógica você condicionar a este arquivo mais saudável ficará seu código.

Como dito ao falarmos de MVC o Controller invoca Models que são classe de negócio onde o Controller irá buscar informações necessárias para o funcionamento do módulo, geralmente encontradas na base de dados.

Certo com o backend parcialmente esclarecido vamos ver como funciona o frontend

Para que aquela URL abra uma página ela precisa saber qual template ela deve invocar e a maneira mais saudável para se fazer isso é através de um arquivo xml.

<cep_busca_editar>
<label>Consulta de CEP</label>
<reference name="root">
<action method="setTemplate">
<template>page/1column.phtml</template>
</action>
</reference>
<reference name="content">
<block type="bobby_cep/busca" name="bobby_cep_busca" template="bobby/cep/busca.phtml" />
</reference>
</cep_busca_editar>

Em negrito seguem as partes alteráveis deste código primeiramente root é a referência principal lá ele determina qual será o layout básico da página baseada em padrões do Magento ou do tema instalado, no caso queremos que nossa pagina tenha um layout de uma coluna.

Em content nós passamos três parametros: type, onde ele determina em qual bloco o layout deve ser basear para contruir a página, este bloco está declarado dentro da pasta Block do nosso módulo e tem funções que podem ser invocadas no decorrer do arquivo como se fossem pequenas chamadas no backend para informações pontuais necessárias ao frontend, estendendo aí a funcionalidade da página.

Name é simplesmente o nome de referência do módulo no xml para diferenciá-lo dos demais e template é onde será determinado o caminho do arquivo (P)HTML que será a formatação de nossa página.

Dentro deste arquivo phtml está todo o HTML da página e também chamadas a funções existentes dentro do bloco:

Ex: $this->getCep() dentro do bloco Busca.php lembre-se do (type=”bobby_cep/busca” existente no xml), há um método chamado getCep(), que retornará algo importante para aquela parte da página, não confundir com métodos do controller que sempre rodam (ou melhor só a action irá rodar) toda vez que a página é carregada.

Pronto já temos nossa página estamos usando nesta brincadeira controllers, models, blocks, xml e arquivos de template, sem contar que tudo isso deve estar devidamente configurado no arquivo config.xml na pasta etc, onde todos estes arquivos irão se conhecer, que merece um post a parte que ainda será lançado 😉

Para quem conhece o CMS do Magento criar uma página dessa forma apesar de ser mais trabalhoso, é muito melhor pois oferece toda a possibilidade lógica que o magento oferece o CMS serve apenas para páginas estáticas com textos estáticos que podem ser editados pelo merchant.

Bom sabendo como funcionam as páginas criadas no magento vamos nos aprofundar no FrontController

O Front Controller

Como dito no início, esta é a classe do Magento que manipula toda a lógica, junta blocos e objetos e o renderiza e captura seus requests e responses.

Ele realiza basicamente 5 ações:

– Captura os routers através da URL, inicializando os métodos

– Aplica URL rewrites pela base de dados, ou seja ele reescreve a URL a tornando amigável por exemplo colocando o id do produto retornado na base nesta url dessa forma …/product/id/56 ao invés de …/product.php?id=56.

– Aplica URL amigáveis baseadas em configurações dos módulos e do magento.

– Invoca os arquivos corretos através dos routers capturados

– Gera as saídas corretas dos controllers que herdam seus métodos.

Ao se chamar o FrontController o Magento invoca o método run() do arquivo Mage.php depois Api.php inicializa configurações, cache, indices e final chama o método FrontController.

O FrontController se torna o ponto central do sistema MVC do Magento que é debatido e criticado por alguns especialistas pois:

O FrontController ainda opera no espaço global.

Convenção sobre configuração leva a menos modularidade.

Encaminhamento URLs é muitas vezes inflexível.

Os Controllers são muitas vezes obrigados a views específicas, como vimos cada URL tem o seu template.

Mesmo quando um sistema oferece uma forma de substituir esses padrões, a convenção leva a aplicações onde é difícil / impossível a cair em um novo modelo novo, ver, ou Controller de implementação sem grande reestruturação.

Porém o processo procura inibir esses pontos pois funciona da seguinte forma:

1. Uma URL é interceptado por um único arquivo PHP.

2. Este arquivo PHP instancia um aplicativo Magento.

3. A aplicação Magento instancia um objeto Front Controller.

4. Front Controller instancia qualquer número de objetos Router (especificados na configuração global).

5. Roteadores verificam a URL de solicitação para um “match”.

6. Se for encontrada uma correspondência, um Controller e uma Action são derivadas.

7. O Action Controller é instanciado e o nome do método de correspondência e o nome da Action são chamados.

8. Esta Action irá instanciar e chamar métodos em modelos, dependendo do pedido.

9. Esta Action Controller, então, irá instanciar um objeto de layout.

10. Este objeto de layout irá, com base algumas variáveis ​​pedido e propriedades do sistema (também conhecido como “getters”), criar uma lista de objetos do bloco que são válidos para este pedido.

11. O layout também chamar um método de saída do Block (como vimos no início do post) que começam uma renderização aninhada (Blocos irão incluir outros blocos).

12. Cada bloco tem um arquivo de modelo correspondente. Blocos de conter a lógica PHP, modelos contêm código de saída HTML e PHP.

13. Blocos irão se referir diretamente para os modelos para seus dados. Em outras palavras, o Controller não os interceptará em nenhum momento, mantendo assim a modularidade do código.

Bom no próximo post iremos traduzir um Wiki do Magento que mostra um passo a passo para a construção do módulo e criar páginas baseadas nos conceitos aprendidos neste post, até a próxima.

2017-01-24T20:24:39+00:00

RECEBA DICAS VALIOSAS NO SEU EMAIL

x