Trabalhando com ambientes no application.ini do Zend Framework

Opa!!!

Muito bem, hoje vamos começar a falar sobre o application.ini e algumas configurações que podemos fazer nele. O artigo de hoje é rápido e simples, pois é quase uma introdução.

Ao criar um projeto pelo Zend_Tool, temos como padrão o seguinte arquivo application.ini:

[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
appnamespace = "Application"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.frontController.params.displayExceptions = 0

[staging : production]

[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.frontController.params.displayExceptions = 1

O que seriam os ambientes? Seriam as seções de configurações. No caso do exemplo acima, temos os ambientes production, staging, testing e development. Como você vai usar cada um deles vai depender bastante de você, mas eu utilizo o ambiente production para as configurações do servidor de produção (maior parte das configurações). O ambiente testing eu utilizo assim que coloco um projeto no ar, mas enquanto estou fazendo alguns ajustes para o ambiente de produção e preciso ver possíveis erros sendo exibidos na tela (e não gravados em log). O ambiente development é o ambiente que eu utilizo enquanto estou desenvolvendo, onde preciso que todos os erros sejam exibidos.

Porque isto é tão interessante? Porque podemos ter configurações únicas para cada ambiente. Por exemplo, a exibição de erros, como citado acima. Outro exemplo clássico de utilização é para dados de acesso ao banco de dados, já que nome do banco, usuário e senha podem ser (normalmente são) diferentes do ambiente de desenvolvimento e em produção.

Definindo o ambiente atual

Podemos definir qual o ambiente atual basicamente de 3 formas:

• index.php (não indico)
• Virtual Host (normalmente em desenvolvimento)
• .htaccess (o que eu mais gosto)

index.php

No index.php padrão, criado pelo Zend_Tool, temos as seguintes linhas:

defined('APPLICATION_ENV')
    || define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ? getenv('APPLICATION_ENV') : 'production'));

O que ele verifica? Se a constante APPLICATION_ENV está definida. Se ela não está definida, será definida. Aí verifica se está setada uma variável de ambiente (função getenv) com o nome APPLICATION_ENV. Se existir, pega o seu valor e atribui à constante. Se não existir, define como production.

Então, para definir o ambiente no index.php podemos fazer o seguinte:

<?php
define('APPLICATION_ENV', 'development');

// Define application environment
defined('APPLICATION_ENV')
    || define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ? getenv('APPLICATION_ENV') : 'production'));

Pronto. Temos o ambiente definido como development para a aplicação. Eu não gosto muito de fazer assim, porque acho que o arquivo index.php não deve ser editado para isto. Além disto, as linhas abaixo do define que foi adicionado ficam sem sentido, mas algum outro programador pode pegar o projeto para dar manutenção e não vai procurar ali para definir o ambiente (normalmente).

Virtual Host

No exemplo de criação de Virtual Host do Zend Framework ele mostra como fazer a mesma coisa utilizando Virtual Host.

<VirtualHost *:80>
        ServerName quickstart.local
        DocumentRoot /path/to/quickstart/public

        SetEnv APPLICATION_ENV "development"

        <Directory /path/to/quickstart/public>
                DirectoryIndex index.php
                AllowOverride All
                Order allow,deny
                Allow from all
        </Directory>
</VirtualHost>

Vejam que definimos uma variável de ambiente SetEnv APPLICATION_ENV “development” (lembra que o index.php busca por uma variável de ambiente com este nome?) definida com o valor de development. Não gosto desta forma porque, normalmente, não temos acesso à criação de Virtual Host no servidor de produção, mas é uma ótima forma de fazer isto no ambiente de desenvolvimento.

Via .htaccess

Utilizamos a mesma ideia do Virtual Host, mas adicionando a linha ao arquivo .htaccess. Assim:

SetEnv APPLICATION_ENV "development"
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

Vejam que a forma e o efeito é exatamente o mesmo que utilizando o Virtual Host, com uma grande diferença: flexibilidade. No ambiente de produção podemos criar arquivo .htaccess e definir, de forma simples e rápida, uma mudança no ambiente, sem depender de configuração do servidor. Outro motivo é que normalmente você envia o arquivo .htaccess somente uma vez para o servidor e praticamente não modifica ele (isto será útil mais abaixo).

Herança dos ambientes

[development : production]

Olhando o trecho acima de código, percebemos que existe algo que não foi falado ainda. O que é este : production? Herança!!! Ou seja, o ambiente development recebe todas as configurações do ambiente production, podendo sobrescrever qualquer uma delas. Por isto que temos a definição da exibição de erros e exceções na seção production (seção pai) e na seção development (seção filha).

Criando novos ambientes

Por padrão o Zend traz os ambientes citados acima, mas nada impede que você crie, modifique ou remova um ou mais ambientes que você não estiver utilizando. Imagine que, por algum motivo bizarro (já passei por isto) você precisa testar uma aplicação em 3 servidores diferentes (!!!). Como fazer, se os dados de acesso ao banco de dados são diferentes em cada um dos servidores? Simples! Defina 2 seções extras e coloque ali dentro os dados de acesso ao banco de dados de cada servidor. Modifique o arquivo .htaccess de cada um dos servidores (viu como falei que seria útil?) para trabalhar no ambiente escolhido e pronto.

Outro caso que você pode usar é para colocar o site/aplicação em manutenção, mas isto é assunto para outro artigo – link aqui.

Por hoje era só isto, mas fique ligado que teremos mais artigos sobre o application.ini. Gostou? Comente e compartilhe!!!

Abraços