Incluí no projeto CakePtbr o model EstadoBrasileiro e o helper Estados. Ambos são relacionados aos estados brasileiros, facilitando o uso nos formulários e models.

Documentação e códigos encontram-se no projeto.

Agora no plugin CakeBr há o helper chamado Formatacao para facilitar a formatação de datas e números. Os seguintes métodos podem ser utilizados:

• data($data = null) Formata uma data timestamp no formato dd/mm/YYYY. Se não for informada a data, será utilizada a data atual
• dataHora($dataHora = null, $segundos = true) Idem anterior, porém com a informação da hora junto.
• dataCompleta($dataHora = null) Mostra a data completa. Exemplo: ‘terça-feira, 21 de abril de 2009, 10:00:00′.
• precisao($numero, $casasDecimais = 3) Similar ao método precision do helper Time, mostrando os números no formato brasileiro.
• porcentagem($numero, $casasDecimais = 2) Mostra o valor em porcentos, similar ao toPorcentage do TimeHelper.
• moeda($valor, $opcoes = array()) Mostra o valor em reais. Exemplo: R$ 10,20.
• moedaPorExtenso($numero) Escreve o valor por extenso, em reais.

Caso alguém tenha mais algum método para incluir, basta informar ou criar um fork no projeto.

O código está junto do projeto Cake PT-BR, no GitHub.

Similar ao Behavior de Validação, as funções dos Correios foram colocadas dentro de um Behavior. O nome dele é Correios (sugestivo ). Nesse behavior há dois métodos:

• valorFrete: calcula o valor do frete. Parâmetros:
  • servico: define o tipo de serviço que será feito. Os valores válidos são através das constantes: CORREIOS_SEDEX, CORREIOS_SEDEX_A_COBRAR, CORREIOS_SEDEX_10, CORREIOS_SEDEX_HOJE, CORREIOS_E_SEDEX, CORREIOS_ENCOMENDA_NORMAL, CORREIOS_PAC.
  • cepOrigem: Cep de origem no formato XXXXX-XXX.
  • cepDestino: Cep de destino no formato XXXXX-XXX.
  • peso: Peso, em quilos, do item a ser transportado. O valor deve ser um número e não deve ultrapassar 30.
  • maoPropria:(opcional. Padrão falso) Valor boleano para indicar se o transporte é com mão prórpria.
  • valorDeclarado: (opcional. Padrão 0.00) Valor do item a ser transportado.
  • avisoRecebimento: (opcional. Padrão falso) Calculo com aviso de recebimento.

  O retorno será negativo em caso de erro, que podem ser as constantes:

  • ERRO_CORREIOS_PARAMETROS_INVALIDOS: Um ou mais parâmetros com formato ou conteúdo inválido.
  • ERRO_CORREIOS_EXCESSO_PESO: Peso acima do limite (30 Kg).
  • ERRO_CORREIOS_FALHA_COMUNICACAO: Problema de comunicação com o site dos Correios.
  • ERRO_CORREIOS_CONTEUDO_INVALIDO: O conteúdo retornado pelo Correios não é o esperado.

  Em caso de sucesso, será retornado um array com os seguintes indices:

  • ufOrigem: UF da Origem
  • ufDestino: UF do Destino
  • capitalOrigem: Valor booleano indicando se a origem é considerada capital
  • capitalDestino: Valor booleando indicando se o destino é considerado capital
  • valorMaoPropria: Valor, em reais, da mão própria
  • valorTarifaValorDeclarado: Valor da tarifa pelo valor declarado
  • valorFrete: Valor apenas do frente, sem incluir os valores de mão própria e tarifa do valor declarado
  • valorTotal: Soma de todos os valores anteriores
• endereco: Informa o endereço baseado em algum CEP. O único parâmetro é o CEP no formato XXXXX-XXX. Os valores de retorno podem ser as constantes ERRO_CORREIOS_PARAMETROS_INVALIDOS, ERRO_CORREIOS_FALHA_COMUNICACAO ou ERRO_CORREIOS_CONTEUDO_INVALIDO em caso de erro. Em caso de sucesso, o retorno será um array com os indices logradouro, bairro, cidade e uf.

Bem, agora vamos aos códigos. Um exemplo usando o behavior:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

class Correios extends AppModel {
	var $name = 'Correios';
	var $useTable = false;
	var $actsAs = array('CakeBr.Correios');
 
	function frete($cepDestino) {
		// Supondo que é uma loja que transporta produtos pequenos (até 1Kg)
		return $this->valorFrete(CORREIOS_SEDEX, Configure::read('Loja.CEP'), $cepDestino, 1.0);
	}
}
 
// Outro caso
class Endereco extends AppModel {
	var $name = 'Endereco';
	var $actsAs = array('CakeBr.Correios');
 
	function beforeSave($options) {
		$endereco = $this->endereco($this->data['Endereco']['CEP']);
		if ($endereco < 0) {
			return false;
		}
		$this->data['Endereco'] = array_merge($this->data['Endereco'], $endereco); // Aqui serão incluídas as informações de logradouro, bairro, cidade e uf.
	}
}

Qualquer dúvida, estamos aí.

O código está junto do projeto CakePTBR no GitHub. Eu coloquei ele na forma de plugin, então basta copiar a pasta plugins para dentro do seu projeto (pasta app). Feito isto, ele já instalado e já pode ser usado nas models.

Nas models, deve ser incluído o behavior e usar a validação normalmente. Exemplo:

1
2
3
4
5
6
7
8
9

class Usuario extends AppModel {
	var $name = 'Usuario';
	var $actsAs = array('CakeBr.Validacao'); // Aqui inclui o behavior do plugin CakeBr
	var $validates = array(
		'cpf' => array(
			'rule' => 'cpf'
		)
	);
}

Este exemplo mostra como validar o campo cpf. Mais detalhes de como funciona a validação, veja no CookBook.

Bem, mas afinal, o que será validado?! Vamos detalhas um pouco mais cada uma das quatro funções de validação:

CPF

Se a regra for declarada apenas como cpf (idem exemplo acima), ele irá validar o CPF no formato XXX.XXX.XXX-XX e também fará o teste do dígito verificador (dois últimos números) para verificar se é um CPF válido.  Em determinadas situações, deseja-se enviar pro banco apenas os números, sem a formatação, pra isso, coloquei um parâmetro opcional que pode ser passado para fazer este teste. Na rule, deve ser colocado:

1
2
3
4
5

	var $validates = array(
		'cpf' => array(
			'rule' => array('cpf', true)
		)
	);

Deste modo ele irá validar apenas números.

CNPJ

Mesmo funcionamento do CPF, porém para CNPJ. A regra de apenas números também é válida. O formato do CPNJ é considerado XX.XXX.XXX/XXXX-XX.

CEP

O CEP, por padrão vai ser considerado nos formatos XXXXXXXX ou XXXXX-XXX. Caso queira alterar o separador, você pode definir da seguinte maneira:

1
2
3
4
5

	var $validates = array(
		'cep' => array(
			'rule' => array('cep', array('', '-', '.'))
		)
	);

No exemplo acima, ele vai validar os valores padrões e XXXXX.XXX.

Telefone

A validação do telefone se dará através das formatações:

• XXXX-XXXX
• (XX) XXXX-XXX (o espaço entre o fechamento de parênteses e o número é opcional, mas limitado a 1 espaço)
• +XX (XX) XXXX-XXXX (idem anterior sobre o espaçamento)

Caso deseje validar apenas números, passar o parâmetro true na validação. Neste caso, ele validará números com 8 ou 10 caracteres.

Bem, são estas as validações que fiz por enquanto. Caso alguém tenha uma sugestão de nova validação ou dúvida sobre as apresentadas, fique a vontade de comentar.

Maiores informações poderão ser obtidas no próprio site (ou até com ele mesmo): http://blog.renangoncalves.com/2009/04/14/i-encontro-de-cakephp-em-sao-paulo/

Esperamos que o evento venha a fortalecer o CakePHP no mercado e a comunicação entre os desenvolvedores com os maiores nomes em âmbito nacional.

Não deixem de ler a reportagem que é muito boa e que sem dúvida ajuda a levar o CakePHP cada vez mais aos sites e sistemas web.

Parabéns a revista e a todos que participaram!

Ainda não há data, local, previsão do tempo ou afins, mas que provavelmente será em São Paulo/SP. Confiram no site deles para maiores informações.

Abraços e vamos tentar ir pra lá, vamos fazer parte do primeiro encontro de Cakers do Brasil.

Abraços e bons projetos a todos.

Natal é legal para trocar presentes, unir família e tudo mais, mas isso dura algumas horas, nas demais ficamos sem ter o que fazer, até mesmo porque o comércio não abre. Com isso, resolvi fazer alguns testes nos principais frameworks PHP que estão no mercado: CakePHP, Code Igniter, Symfony, Yii e Zend Framework.

Todos os benchmarks que eu vejo pela internet são de um simples hello world, que às vezes não utilizam o framework como indicado e acaba desvirtuando um pouco. Além disso, muitos testam somente a versão estável, deixando pra lá algumas versões mais “quentes”, como no caso do CakePHP 1.2. Então resolvi mudar! Fiz um teste com o famoso Hello World, e outros dois: um acessando o banco de dados e lendo 10 registros e o mesmo código lendo 1000 registros. Assim, aproxima um pouco da realidade do desenvolvimento, pois não desenvolvemos Hello Worlds, mas sim acesso a banco, uso de MVC (completo e não como os exemplos que não há view!). Não testei as funcionalidades em si de cada framework como cache, ACL, componentes, etc, detive-me ao básico, acessar o banco e mostrar um dos campos.

Bem, vamos começar falando da máquina de testes. Estava rodando num Debian Etch, com processador Intel Xeon 2.66GHz, 256MB de RAM. Esta máquina é um servidor de produção que é vendido pela VirtuaServer. Ou seja, tentei fazer o teste num servidor que usamos na prática e não numa máquina local de qualquer desenvolvedor. Nesta máquina a versão do Apache é a 2.2.3, PHP 5.2.0 e MySQL 5.0.32. Nenhuma extensão de cache/performance (APC, Memcache, etc) está habilitada.

O desenvolvimento da aplicação eu fiz me baseando na documentação de cada framework e não a partir de exemplos prontos, pois queria fazer seguindo a lógica dos desenvolvedores de cada framework. Tentei deixar o mais próximo do modo de produção (desabilitando debugs, etc).

Vamos aos resultados, começando pelo famoso Hello World:

O eixo Y representa o número de requisições completadas após 30 segundos de testes. Usei a ferramenta “ab” para fazer os testes (parâmetros: -t 30 -c 10 ou -c 100. Isso significa que testei cada framework por 30 segundos, com 10 ou 100 requisições em paralelo).

Como podem ver, Yii e CodeIgniter apresentaram excelentes resultados, enquanto os demais ficaram próximos. Alguns poderiam dizer  que o CakePHP apresenta resultados inferiores por manter suporte ao PHP4, o que limita algumas coisas, mas lembro que o CodeIgniter também suporta o PHP4 e apresentou resultados surpreendentes.

PS: Fiz as aplicações antes de iniciar todos os testes, ou seja, a parte de banco de dados já estava configurada até para fazer o Hello World, então caberia a aplicação conectar/carregar “drivers” ou não…

Ok, agora vamos aos resultados dos testes dos frameworks acessando a base de dados e mostrando 10 registros:

Novamente Yii e CodeIgniter se sobressaindo… Porém, vejam que o CakePHP estável (1.1) obteve melhores resultados que o CakePHP 1.2 e mais, o CakePHP 1.2 obteve o pior resultados dos pesquisados.

Outra coisa interessante que podemos notar é que o CodeIgniter tem uma performance melhor com mais requisições em paralelo, sendo mais interessante para sites de grande porte, como portais que tem bastante acesso.

E agora o último teste: acesso ao banco com 1000 registros. A idéia deste teste é tentar visualizar se o framework tem um overhead grande por causa de registros ou por causa da pesquisa. Se pensarmos, a pesquisa é a mesma, a quantidade de registros retornados é que mudará, então é neste ponto que vamos notar as diferenças.

CodeIgniter novamente se destacando e ainda deixando o Yii mais distante que nos demais testes. Nota-se também que todos têm um overhead grande sobre os registros retornados no banco, pois diminuíram muito sua performance. O CakePHP 1.2 reduziu pouco, o que é interessante.

Vale ressaltar que o teste com 1000 registros não é tão usado na prática, pois uma página com 1000 registros pro usuário ler é um tanto quanto chato. Normalmente nestes casos há paginação. Exemplos práticos que vejo disto é na geração de relatório ou gráficos, mas que são pontos isolados e não tão usuais.

Alguns comentários sobre os desenvolvimentos das aplicações de teste:

• Do CakePHP eu não posso falar nada, pois já trabalho com ele a mais de dois anos. Os demais, desconhecia quase que totalmente;
• O Zend Framework eu tive um trabalho imenso para conseguir fazer o banco de dados funcionar. Na documentação deles eles falaram várias coisas que podem ser feitas, mas não dizem a básica: aonde vão os arquivos;
• No Zend eles recomendam que as requisições que só vão retornar textos simples seja feito no controller, por exemplo, na action do controller você coloca um die ou exit. Eu acho que isso quebra o MVC e em grandes projetos fica uma salada de fruta;
• Ainda no Zend eles recomendam que os arquivos que não são de view (não teham HTML) você não feche a tag do PHP (?>), assim evita que fiquem linhas em branco no arquivo e dê os famosos erros de não conseguir escrever no header. Ok, isso é legal, mas não fechar as tags eu acho que é amadorismo. Se o cara fechou e deixou uma linha em branco, é desatenção e deve ser corrigido e não contornado.
• O Symfony eu não sei direito tudo que ele gerou, sei que eu executava alguns comandos (indicados na documentação) e ele fazia as coisas acontecerem. Não encontrei na documentação sobre a lógica e como desenvolver manualmente…
• No Symfony, também tive problema em configurar o banco de dados, pois na documentação estava errada, mas em algumas pesquisas do Google eu achei;
• O Yii parece fácil de usar. Ele tem certas similaridades com o CakePHP (exceto na performance, como foi visto);
• Code Igniter também foi tranqüilo o desenvolvimento. A estrutura de diretórios é similar a do CakePHP, facilitando um pouco.

Minhas opiniões quanto os resultados:

• CakePHP, Yii e CodeIgniter são fáceis de desenvolver, tem uma boa organização e estruturação, ficando legíveis e bons para se trabalhar em equipes diversificadas;
• A documentação do Zend e Symfony são meio obscuras para “dummies”, tendo que quebrar um pouco a cabeça para conseguir fazer coisas simples (como o acesso ao banco).  Para quem está começando, acho que isso é um tanto quanto chato e desestimulante…
• Yii e CodeIgniter parecem ter bom desempenho na prática, porém desconheço dos recursos e de como é a forma de desenvolvimento. Temos que ver se eles não são muito amarrados aos recursos internos e não dão suporte a integração com outras aplicações/componentes.  Entretanto, se eu fosse começar um desenvolvimento hoje, estudaria um pouco mais esses dois;
• Yii é focado para web 2.0 e trabalha com jQuery (que é a onda do momento em JavaScript). Interessante… Acho que se ele incorporar algumas funcionalidades mais comerciais (testes automatizados, etc) ele terá futuro promissor e não será um fogo de palha;
• O CakePHP ainda parece o mais “potente” do mercado e tem uma boa visão comercial. Enquanto que a maioria se preocupa em fazer site “legal”, o CakePHP dá essa possibilidade e ao mesmo tempo oferece um suporte a desenvolvimento para empresas, com facilidades para desenvolvimento utilizando métodos ágeis, testes automatizados, etc.

Bem, acho que é isso. Não vou largar do CakePHP, mas não custa dar uma estudada mais a fundo nos outros.

Caso alguém tenha alguma sugestão de testes a fazer, comente! Pois vou deixar minha suite de testes montada para quando sair novas versões fazer a comparação.

Caso queiram ver os testes mais detalhados, podem acessar os últimos resultados dos testes. Neste site também está disponível o resultado mais detalhado de cada teste, inclusive os números.

Abraços.

• O arquivo app/webroot/css.php foi completamente modificado, então é necessário substituí-lo;
• Classregistry::_duplicate() agora é um método privado (Classregistry::__duplicate());
• Router::matchRoute() agora é um método privado (Router::__matchRoute());
• O parâmetro de Xml::toArray() foi substituído de “$object = null” para “$camelize = true”;
• Os métodos setAro(), setAco(), getAro() e getAco() foram removidos da classe Acl;
• O método Model::normalizeFindParams() foi removido;
• O parâmetro safe do helper Javascript foi removida;
• O método Model::getDisplayField() foi marcado como depreciado. Agora deve ser acessada a propriedade displayField ($model->displayField).

Boa sorte na migração.