[ Zend Framework 2 ] – Sistema de Configuração

Este post tem como objetivo demonstrar o funcionamento do sistema de configuração do Zend Framework 2 em suas diversas formas, sua modularidade e o melhor local para cada caso.

Zend Framework 1 x Zend Framework 2

NOTA:
Neste tutorial utilizei a estrutura esqueleto padrão.

Acostumados com o famoso arquivo de configuração application.ini, os desenvolvedores agora têm uma estrutura totalmente diferente de definir configurações no ZF2.

A nova versão do framework utiliza o carregamento de arquivos com retorno de Arrays para prover configurações ao sistema.

Vamos analisar a seguir o comportamento desta nova estrutura e ver como podemos tirar proveito das novidades oferecidas pelo ZF2.

Arquivos de Configuração

As configurações, como vimos anteriormente, são providas por arquivos, exceto o caso dos Modules que podem definir seus Arrays de configuração diretamente em seu método getConfig() per-modulo ou via um arquivo que fica localizado exclusivamente dentro da estrutura de arquivos do Modulo, a fim de oferecer SoC(Separation Of Concerns), do inglês Separação de Conceitos .

Basicamente, temos:

  1. <caminho>/config/application.config.php
  2. <caminho>/modules/<modulo>/config/module.config.php
  3. <caminho>/config/autoload/global.php
  4. <caminho>/config/autoload/local.php

OBS.: Existe o arquivo <caminho>/init_autoloader.php que possui configurações para o autocarregamento de classes no Framework, no entanto, ele diverge consideravelmente dos listados acima, pois possui alguma lógica e se trata de um arquivo de processamento, diferente dos demais que somente possuem um Array de configuração.

Voltando aos nossos arquivos de configuração:

No caso 1 este arquivo é passado como argumento para o inicializador da Aplicação diretamente no arquivo index.php. Basicamente, o que esta chamada faz é definir um serviço interno chamado “ApplicationConfig” que será utilizado pelo gerenciador de Módulos. Logo, você pode subentender que não está acontecendo muita coisa aqui até que um módulo seja chamado.

O caso 2 como ja foi mencionado, funciona per-modulo e trataremos adiante dele.

No caso 3 define as configurações não são sensíveis à questões de segurança. As definições feitas aqui sobreescrevem as que foram feitas via Modulo, por isto certifique-se que uma ou mais definições não foram definidas neste arquivo antes de criá-las no seu Módulo.

No caso 4 define as configurações que são sensíveis à questões de segurança. Também sobreescrevem as feitas via Módulo.

// Configurações de autoloading
require 'init_autoloader.php';
// Executa a aplicação
Zend\Mvc\Application::init(require 'config/application.config.php')->run();

Gereciador de Módulos

O gerencimento de módulos citado anteriormente é realizado pela classe ModuleManager.

Esta classe é responsável pelo disparo de alguns eventos:

ModuleEvent::EVENT_LOAD_MODULES
ModuleEvent::EVENT_LOAD_MODULES_POST
ModuleEvent::EVENT_LOAD_MODULE_RESOLVE
ModuleEvent::EVENT_LOAD_MODULE

Destes eventos, o mais importante é o definido por EVENT_LOAD_MODULE (singular).

Não é o foco falar de eventos aqui, mas resumidamente, todo evento (Event) tem um alvo, conhecido por Listener (também Consumer), que é o que “ouve” ou “consome” o evento sendo executado.

Então, precisamos analisar dois Listeners muito importantes aqui:

Zend\ModuleManager\Listener\ConfigListener
Zend\ModuleManager\Listener\ServiceListener

ConfigListener

Este Listener é responsável por chamar as configurações per-módulo através do método getConfig().
Como os arquivos de configuração ja foram consumidos na ordem anterior até chegar aqui, as configurações do Modulo serão mescladas dentro delas.

ServiceListener

O ServiceListener faz uma tarefa similar. Ele chama todas as outras configurações per-módulo para os métodos:

getServiceConfig() //equivalente a $config['service_manager']
getControllerConfig() //equivalente a $config['controllers']
getControllerPluginConfig() //equivalente a $config['controller_plugins']
getViewHelperConfig() //equivalente a $config['view_helpers']
getValidatorConfig() //equivalente a $config['validators']
getFilterConfig() //equivalente a $config['filters']
getFormElementConfig() //equivalente a $config['form_elements']
getRouteConfig() //equivalente a $config['route_manager']

Por fim, cada processo retorna um Array que são mesclados no final do processo.

A ordem de precedência é a mesma da lista acima.

SUGESTÕES PARA LEITURA

Art Of Separation of Concerns – Artigo extenso e interessante sobre Separação de Conceitos.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *