Hoje posso dizer que o conhecimento sobre esses temas é suficiente para poder arriscar palpites e algumas dicas aos menos experientes no assunto. Relacionar o desenvolvimento orientado a testes (tdd) aos padrões de projeto (design patterns) é quase como relacionar pão com manteiga, café com leite, arroz com feijão. Enfim, combinações que você sabe que não andam o tempo inteiro lado a lado, mas que vez ou outra acabam se encontrando.

Quanto a frameworks, não posso dizer que o mesmo conhecimento que eu tinha foi tão modificado. O que se alterou foi apenas a interpretação acerca das características e recursos dos frameworks que sempre tive mais contato e trabalho atualmente: Symfony e Zend Framework.

Com a bagagem de conhecimento que adquiri nesse último ano, trabalhando mais com arquitetura de software do que desenvolvimento para web (html, js, css etc) propriamente dito, posso dizer que já dá para começar a rascunhas alguns textos, artigos e tutorias sobre padrões, testes e frameworks de forma mais ampl

É esperar e ver no que dá

Infelizmente, o helper responsável pela escrita dessas urls ainda é bastante imaturo. A forma como deve ser feita esta tarefa é trabalhosa, chata e principalmente, improdutiva. Só o fato de ter de indicar “TODOS” os parâmetros para a escrita da URL em uma estrutura de array associativa soa como um paradoxo, já que o próprio framework possui mecanismos que fazem o parser na url requisitada, identificando os parâmetros necessários e passando-os ao roteador. Ou seja, é um retrabalho e não um reúso. Exemplo de uma url escrita da forma padrão em um arquivo de template.

< ?php
echo $this->url(array(
    'controller' => 'users',
    'action'  => 'edit',
    'id'  => 25
));
?>

A saída do exemplo será: /users/edit/id/25. Analisando a url, seria mais fácil simplesmente escrever da seguinte forma:

< ?php echo "/users/edit/id/25"; ?>

Desta forma o resultado é mais rápido, porém, você perde em termos controle, já que a escrita é manual e se você alterar o nome do controle ou da ação, a url passará a ser inválida (a não ser que você use roteadores customizados).

A maioria dos frameworks, como Symfony, Cake etc, implementam tanto a forma de escrita com os parâmetros em um array, quanto uma string contendo a url desejada, fazendo a conversão automática dos mesmos para o formato padrão do framework ou da aplicação. O Symfony, por exemplo, implementa a escrita da seguinte forma:

< ?php echo url_for('users/edit?id='. 25); ?>

O Symfony automaticamente converterá isso para o formato /users/edit/id/25. Considero essa forma muito mais elegante e produtiva, pois está mais próximo da realidade das urls “dinâmicas”. No entanto, se houver mais parâmetros, a coisa já começa a complicar.

Voltando a forma como o Zend Framework implementa este recurso, já se sabe que ele não é tão flexível assim, então é necessário criar um helper na camada de visualização para esta tarefa. Podemos inclusive, aproveitar o que já foi desenvolvido e é padrão do framework e encontra-se na pasta: Zend/View/Helper/Url.php.

< ?php
#Zend/View/Helper/Url.php

class Zend_View_Helper_Url extends Zend_View_Helper_Abstract
 {
 	public function url(array $urlOptions = array(), $name = null, $reset = false, $encode = true)
 	{
 	$router = Zend_Controller_Front::getInstance()->getRouter();
 	return $router->assemble($urlOptions, $name, $reset, $encode);
 	}
 }

Crie um arquivo de helper com o nome que você quiser e o coloque no diretório de helpers da sua aplicação. O meu eu chamei de MyUrl.php. Crie neste arquivo a classe Zend_View_Helper_MyUrl. Dentro da classe, crie o método myUrl. É importante ressaltar que o nome do helper deve estar no nome do arquivo, como sufixo do nome da classe e como método principal, que é avaliado e chamado pelo objeto Zend_View ao ser requisitado no template.

O método myUrl terá os mesmos parâmetros do helper Url, com exceção que o primeiro parametro poderá tanto ser uma string quanto um array, então não é necessário tipá-la.

A classe então terá a seguinte estrutura.

< ?php
require_once 'Zend/View/Helper/Abstract.php';
 
class Zend_View_Helper_MyUrl extends Zend_View_Helper_Abstract
{ 
     /**
       * Return the URL
       *
       * @param string|array $urlOptions
       * @param string       $name
       * @param bool         $reset
       * @param bool         $encode
       * @return string
       */
       public function myUrl($urlOptions, $name = null, $reset = false, $encode = true)
       {
          $front  = Zend_Controller_Front::getInstance();
          $router = $front->getRouter();
 
          if (is_string($urlOptions)) {
             $urlOptions = '/'. ltrim($urlOptions, '/'); // Case the first character is a '?
             $request = new Zend_Controller_Request_Http(); // Creates a cleaned instance of request http
             $request->setBaseUrl($front->getBaseUrl());
             $request->setRequestUri($urlOptions);
             $route = $router->route($request); // Return the request route with params modifieds
             $urlOptions = $route->getParams();
          }
 	  return  $router->assemble((array) $urlOptions, $name, $reset, $encode);
      }
 }

Salvo o helper, é só utilizá-lo. Agora ele suporta todos os formatos:

< ?php echo $this->myUrl(array(
   'controller'=> 'users',
   'action' => 'edit',
   'id'  => 25
)); ?>

ou

< ?php echo $this->myUrl('users/edit?id=25'); ?>

ou

< ?php echo $this->myUrl('users/edit/id/25'); ?>

Muito mais simples, elegante e bem produtivo!

É possível ainda utilizar os outros parâmetros do helper padrão, como o nome do roteador a ser utilizado para formatar a url, se o mesmo vai ou não utilizar a url base ou somente a partir da atual e se a url será codificada ou não – bastante útil para utilizar como valor de outros parametros.

Até a próxima.

Além do suporte ao AMF, os componentes FileTransfer e ProgressBar foram dois adicionais importantes para upload e download de arquivos e verificação do status de envio e carregamento de arquivos, respectivamente. Mas, ainda precisam amadurecer bastante, pois há muita coisa não implementada, principalmente no FileTransfer, que não tem implementação para download e somente suporta o protocolo HTTP.

Um componente bacana que fazia muita falta era o de paginação, que no ZendFramework, serve não só para paginar resultados de consultas de banco, mas também para datasources oriundos de xmls, arrays, desde que os mesmos implementem ou a interface Iterator. Como é quase certo que boa parte da utilização desse componente é com banco de dados, implementaram agora o suporte ao Zend_Db_Table. Isso é muito importante na hora de paginar, pois o Paginator apenas implementava a paginação e executa os resultados retornando um objeto ArrayIterator apenas, dificultando bastante a tarefa de paginar os resultados de uma tabela extendida do Zend_Db_Table, que teria que ser feito manualmente pelo método limit no select da tabela. Agora o paginator já faz isso, bastando apenas passar o objeto da tabela, que o fará utilizar o adaptador DbTableSelect.

Outra novidade, é o ZendX, que nessa versão, traz o componente Zend_JQuery, que suportará métodos para escrita de código javascript na camada de visualização. Isso é um passo importante, pois o Zend Framework já suporta o Dojo, e como há uma variedade frameworks javascript, é interessante esse suporte. O mais legal é que não será preciso dizer ao script de visualização que componente você utilizará, mas, apenas escrever o método relativo a funcionaliadde javascript que deseja e o framework se encarrega do resto. Como o jQuery é praticamente o mais famoso e mais utilizado hoje, é certo que esse componente fará uma grande diferença no futuro.

Também foi promovido ao incubator, o Zend_Tool, componente que proverá classes para geração de código Php, interface em linha de comando para criação e gerenciamento de projetos MVC em ZendFramework, que para mim era o que faltava para ser de fato o melhor framework, pois há muito tempo os demais já ofereciam essa opção, como o Symfony. Alías, esse será o foco do framework na versão 1.8, o desenvolvimento rápido de aplicações, ou RAD, do termo em inglês, para os íntimos.

Na integração de serviços, foi aperfeiçoado o suporte ao GData e adicionado suporte ao Twitter.

O Zend Framework 1.7 está disponível para download here.

Mesmo assim, tive algumas necessidades de implementação, principalmente aquelas relacionadas a banco de dados, que acabei desenvolvendo eu mesmo. Não foi uma tarefa tão difícil, já que o framework oferece os recursos de plugins/helpers, bastando estender as classes nativas do framework e implementar as funcionalidades que necessitava.

A paginação de resultados do banco tanto na camada de visualização quanto na própria abstração do banco e o envio de arquivos por upload foram os recurso que eu precisei implementar na unha mesmo. Para minha grata surpresa, esta nova versão do framework traz dois componentes que fazem exatamente essas tarefas, o Paginator e File Transfer.

Mas como bom beta tester que sou, já vou começar a explorar as novas mudanças até o lançamento da versão final, que deve sair até o fim do ano, presumo.

A proposta dele é excelente, o que possibilita digamos, da criação do seu próprio framework, com a estrutura (scaffold) criada a sua maneira. Existem excelentes artigos já em português falando sobre ele, além de um manual completo de utilização. Por isso não vou me estender falando sobre ele.

Uma das dificuldades de alguns desenvolvedores que começaram a utilizá-lo e alvo de constantes questionamentos é a falta do componente que implementa a camada Model. Apesar de já possuir uma bom componente para abstrair o banco de dados e manipular seus dados sem a necessidade de muitos comandos SQL, a camada model ainda faz uma falta, mesmo não sendo um problema grave, já que é possível utilizar qualquer biblioteca que faça o mapeamento objeto relacional como o Lumine, Propel, Doctrine entre outros. Mas ao utilizar qualquer uma dessas bibliotecas, o componente Zend_Db acaba perdendo um pouco a sua utilidade.

Por isso, resolvi escrever e tentar submeter este componente ao core do ZendFramework. Até o momento tenho duas classes escritas parcialmente em testes: Zend_Model e Zend_Model_Import. A primeira classe mapeia o diretório onde estão as entidades e as carrega a medida que forem sendo necessárias, usando um arquivo XML gerado que armazena dados de conexão ao banco ou simplesmente usando uma conexão já feita anteriormente. A segunda classe lista as tabelas do banco e gera as classes das entidades do modelo automaticamente ou importa a partir de um xml contendo todo o esquema do banco.

Nos próximos posts vou mostrar mais ou menos como estou implementando essa camada e coletar sugestões para futuras alterações, antes de submetê-la.

Até a próxima.

Em minha opinião, o Lumine está entre as melhores ferramentas para gerar e trabalhar um camada de persistência usando o mapeamento objeto relacional de um banco, graças a sua simplicidade de implementação e velocidade na execução dos comandos de inserção e seleção de dados.

Como disse anteriormente, em outro post relatarei em detalhes a ferramenta, que segundo o autor, ainda necessita de uma documentação mais completa que ainda não pôde ser feita devido à falta de tempo do mesmo. Desta forma, quem tiver interesse em contribuir, fique a vontade.

No Lumine existe um arquivo de configuração que é utilizado para todas as operações entre a aplicação e o banco de dados, desde a conexão, carregamento das classes referentes aos objetos relacionais, engenharia reversa, criação deschemas, etc. Este arquivo pode ser gerado tanto em XML quanto em PHP. Particularmente, acredito que o formato PHP é mais interessante por ter as informações de configuração armazenadas em um array , impossibilitando desta forma que um usuário veja esses dados acessando o arquivo direto pela URL, caso o mesmo esteja visível na árvore de diretórios do site. Já comXML isso não acontece, a não ser que você configure os mime types permitidos para acesso externo, ou simplesmente altere a permissão do mesmo arquivo via FTP para que ele não seja lido pelo via browser.

Aqui vou falar apenas do arquivo PHP, uma vez que no XML o trabalho é manual mesmo, não há outra saída. No arquivo de configuração, há duas chaves importantes que são a base para o carregamento das classes de negócio:class-path e use-cache. Veja abaixo um exemplo deste arquivo:

$lumineConfig = array (
	’configuration’ => array (
		‘class-path’ => ‘C:\lumine’,
		‘host’ => ‘localhost’,
		‘database’ => ‘meudatabase’,
		‘dialect’ => ‘mysql’,
		‘port’ => ‘3306′,
		‘user’ => ‘usuario’,
		‘password’ => ‘*****’,
		‘package’ => ‘orm’,
		‘maps’ => ‘map’,
		‘use-cache’ => ‘C:\lumine\cache.txt’,
		‘remove_prefix’ => ”,
		‘acao’ => ‘Iniciar’,
		‘create-classes’ => ‘1′,
		‘create-maps’ => ‘1′,
		‘escape’ => ‘1′,
		‘empty-as-null’ => ‘1′,
		‘generate-accessors’ => ‘1′,
		‘fileDate’ => filemtime(__FILE__)
	),
	’maps’ => array (
	‘map.Pessoa’
	)
);

Repare que o valor do caminho do class-path é o padrão de diretório do Windows. Supondo que o seu servidor de produção seja Linux e que o servidor de testes seja Windows, então é provável que um erro no carregamento das classes aconteça em um dos sistemas por um não reconhecer a árvore de diretório do outro. A solução neste caso seria alterar então o caminho do diretório de forma que cada sistema leia o arquivo que contenha o diretório relativo ao seu sistema de diretório, ou seja, uma versão para o Windows e outro para o Linux. Mas isso não é muito saudável, uma vez que um erro de sincronização poderia fazer com que um arquivo sobrescrevesse o outro. Já passei por esta experiência e posso afirmar que alterar caminhos físicos de diretório manualmente é extremamente trabalhoso e chato.

Este arquivo de configuração pode ser gerado tanto manualmente quanto automaticamente pelo LumineReverse, uma classe utilizada para a construção das classes e mapeamentos xml do banco usando engenharia reversa. Neste processo, o Lumine gera o caminho para as classes, mapeamentos e o cache, de acordo com o sistema operacional em que ele estiver rodando. Por isso, é bom ficar atento a este detalhe.

Uma solução para não ter problemas quanto ao caminho correto, é usar a função dirname do php, que retorna o caminho completo do arquivo passado por parâmetro. Neste caso, o parâmetro é a constante global __FILE__, que indica o caminho do arquivo relativo aoscript que está executando o comando. Exemplo:

<?php
// Caminho original do arquivo: C:\aplicacao\lumine-config.php
echo dirname(__FILE__); // Retorna C:\aplicacao
?>

Mas atenção, isso só é válido se você tiver o lumine-config no mesmo diretório dos diretórios de mapeamento e pacote de classes. Exemplo da estrutura:

aplicacao
/mapeamentos
/pacote
lumine-config.php
cache.txt

Alterando então as diretivas use-cache e class-path para que ambas funcionem em qualquer servidor, com a necessidade apenas de alteração do usuário, host e senha do banco a qual o script irá se conectar, o arquivo ficará assim:

$lumineConfig = array (
	’configuration’ => array (
		‘class-path’ => dirname(__FILE__),
		‘host’ => ‘localhost’,
		‘database’ => ‘meudatabase’,
		‘dialect’ => ‘mysql’,
		‘port’ => ‘3306′,
		‘user’ => ‘usuario’,
		‘password’ => ‘*****’,
		‘package’ => ‘orm’,
		‘maps’ => ‘map’,
		‘use-cache’ => dirname(__FILE__) . ‘/cache.txt’,
		‘remove_prefix’ => ”,
		‘acao’ => ‘Iniciar’,
		‘create-classes’ => ‘1′,
		‘create-maps’ => ‘1′,
		‘escape’ => ‘1′,
		‘empty-as-null’ => ‘1′,
		‘generate-accessors’ => ‘1′,
		‘fileDate’ => filemtime(__FILE__)
	),
	’maps’ => array (
	‘map.Pessoa’
	)
);

Assim, o carregamento verificará o caminho para as classes e para o arquivo cache.txt, de acordo com o que retornar a função dirname, em tempo real, e com o sistema em que o script estiver rodando, eliminando a possibilidade de erros e leitura dos dados por estarem em caminhos diferentes.

Em um outro artigo, falarei sobre o Lumine e introduzirei alguns macetes para inserção e seleção de dados simples e complexos.