A grande vantagem disso é a facilidade de visualização das variáveis, trace exceções, mensagens de NOTICE, WARNING, PARSE ERROR, DEPRECATED, etc.

Muitas pessoas podem ter sofrido a mesma dificuldade que tive, ao habilitar essa funcionalidade. Apesar de as informações do PHP (phpinfo) mostrarem que a biblioteca está carregada, a saída do var_dump não vinha formatada. Após vários testes, seguir várias explicações, entre elas, uma sugeria definir o parâmetro “xdebug.trace_format=1“. Restartando o servidor web, as variáveis continuavam no formato padrão do PHP.

Inicialmente, eu pensei que o problema seria porque estou trabalhando com o Lighttpd e o PHP configurado para trabalhar em modo CGI (FastCGI). Isso ocorreu pois eu utilizava PHP como módulo do Apache e esse era meu servidor web. Ao migrar pra o Lighttpd, instalei o pacote php5-cgi (Debian/Ubuntu) e configurei as diretivas necessárias pra funcionar com aquele.

Felizmente, não há diferença, para essa funcionalidade, utilizar o PHP em modo FastCGI ou módulo do servidor Web. Mesmo se esse mesmo PHP fosse utilizado com o Apache em modo FastCGI, o problema persistiria, ou seja, o problema também não é o Lighttpd.

Quando instalamos o pacote php5-cgi, pelo menos nas distribuições Debian-like, as diretivas de configuração pra trabalhar nesse modo são dispostas em uma pasta separada, geralmente em “/etc/php5/cgi”. Na verdade, além de habilitar a extensão Xdebug, é necessário mudar uma diretiva do PHP, “html_errors”. Pelo menos no php.ini da opção CGI, essa estava desabilitada – html_errors = Off. Quando essa diretiva está Off/0 (zero) / false, o Xdebug não formata variáveis, trace de exceções e reporting de erros.

Portanto, se você está com esse problema, além de habilitar a extensão Xdebug (Veja o Post “Instalando o Xdebug no Debian/Ubuntu”), é necessário habilitar a opção html_errors.

Mas há momentos em que o modelo não representa uma entidade do banco. Por exemplo, pode-se usar o modelo para executar uma função, uma procedure ou uma consulta à uma “View” de banco. Trabalhando nessa estrutura, onde o modelo representa os dados persistidos no banco, esse paradigma é quebrado.

O Zend Framework é bastante flexível em vários quesitos; um deles é o quesito mapeamento de dados, é possível sobrescrever algums métodos da classe herdada (Zend_Db_Table / Zend_Db_Table_Abstract). Um desses é o método “_setupPrimaryKey”, responsável por instanciar a chave primária da tabela; metódo, também, responsável por gerar a exceção quando, no mapeamento, não é encontrada a chave primária à partir das colunas buscadas à partir de um describe da tabela. Todo esse processo é executado automaticamente pelo Zend_Db.

Para resolver esse problema, é necessário forçar o mapeamento manual de algumas variáveis utilizadas pela classe “pai”. Nessa situação, foi suficiente forçar a variável “$this->_cols” para um vetor vazio. Adicionalmente, foi informado como vazio o nome da tabela, porém a classe pai define como sendo o nome da Classe filha o valor dessa variável ($this->_name).

Portanto, para trabalhar nessa estrutura, onde o modelo não representa uma entidade no banco basta sobrescrever o método “_setupPrimaryKey”:

public function _setupPrimaryKey() {
$this->_cols = array();
$this->_name = “”;
}

Pra quem já teve a mesma dificuldade que eu, pra instalar o componente xdebug no PHP, vai ai uma ajuda e tanto. Como utilizo o repositório do Ubuntu pra instalar meus serviços e programas, passei por uma dificuldade com a instalação do componente xdebug.

Eu utilizo o ZendServer Community Edition – um Apache + PHP + Componentes básicos do ZendServer todos num pacote -, e nessa situação, executei o comando padrão: “aptitude install php-5.3-xdebug-zend-server“.

Ao restartar o Apache, a surpresa, o serviço não estava no ar e ao analisar os logs a mensagem, que “diz tudo” e não diz nada:

[notice] caught SIGTERM, shutting down

Pesquisando nas listas do xdebug, encontrei algo que poderia resolver meu problema. Mas antes, tentei mais uma opção, compilar a extensão com o phpize. Fiz o download da última versão do xdebug, e executei os seguintes comandos:

# sudo su
# wget http://xdebug.org/files/xdebug-2.1.0beta2.tgz
# /usr/local/zend/bin/phpize
# ./configure –enable-xdebug –with-php-config=/usr/local/zend/bin/php-config
# make
# cp modules/xdebug.so /usr/local/zend/lib/php_extensions/

Como já havia instalado o xdebug do repositório, ele criou em /usr/local/zend/etc/conf.d um link simbólico “xdebug.ini” para o arquivo “/usr/local/zend/etc/ext.d/xdebug.ini”.

Bom, o detalhe maior está nesse arquivo, portanto não precisávamos dessa etapa de compilação. A extensão instalada do repositório cria a seguinte diretiva:

zend_extension=/usr/local/zend/lib/php_extensions/xdebug.so

Dessa forma, a extensão não é carregada e para matar a charada, basta mudar de “zend_extension” para “extension”, portanto:

extension=/usr/local/zend/lib/php_extensions/xdebug.so

O trabalho de melhoria do PHP, deveria ficar a cargo da própria Zend em parceria com a comunidade, mas parece que eles estão sem tempo e mais interessados no mercado corporativo, com suas ferramentas de desenvolvimento, proteção de código e servidor, do que com o crescimento e melhoria da linguagem.

Mais detalhes estão disponíveis em: http://www.geek.com.br/posts/12221-facebook-reescreve-php-do-zero-e-pode-estar-desenvolvendo-um-compilador-para-a-linguagem