Pra começo de conversa, pra quem não sabe o CakePHP 2.0 é a versão que está em desenvolvimento pelo time do cake. As versões 1.2 e 1.3 são versões estáveis e que daqui para frente só terão correções de bugs, nada de recurso novo. Não há em vista uma versão 1.4 (que seriam novos recursos com compatibilidade pro PHP4).

A versão 2.0 tem como requisito PHP 5.2 em diante. Por este fato, trará muitos recursos novos e facilidades no desenvolvimento das aplicações. Além disso, a versão poderá otimizar muitos itens, tornando a sua aplicação mais rápida ainda.

Alguns itens previstos pro Cake 2.0:

• Fim da compatibilidade com PHP 4
• Lazy load para models, helpers e componentes (Não sabe o que é? Eu explico eu outro post)
• Remover a “mágica” que mudava os textos, adotando o “What you type is what you get” (ou “O que você escrever é o que você verá”).
• Ajustes do código para utilizar classes Spl, interfaces, abstracts, etc. e corrigir a visibilidade dos métodos (public/private/protected)
• As buscas retornarão objetos e não mais arrays, facilitando ações e aumentando a performance
• Helpers, Behaviors e Components poderão ter aliases, ou seja, você poderá fazer seu próprio HtmlHelper e dizer que o helper Html será o seu customizado

Gostou? Essa era só uma palinha sobre o que vem por aí. Em breve mais comentários e detalhes sobre o funcionamento destes itens.

Tinha dito que o nome seria power find, mas depois de ver alguns projetos na internet como o SuperAuth, SuperValidatable, etc., resolvi manter o nome de SuperFind.

Bem, vamos ao que interessa, o que faz e como funciona… Basicamente, ele serve para fazer um find podendo colocar condições de relacionamentos hasMany e HABTM. No CakePHP puro isto não é possível, pois ele joga estas condições na query direto e acaba causando um erro de SQL. Aí você dizer, mas e o Containable?! Bem, ele até faz alguns filtros, mas o filtro que ele faz é em cima do valor retornado da consulta principal. Vamos a um exemplo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

$this->Usuario->find('all', array('contain' => array('Tarefa.nome = "Tarefa 1")));
/* Retorno:
    array(
        array(
            'Usuario' => array('id' => 1, 'nome' => 'Usuario 1'),
            'Tarefa' => array(
                array('id' => 1, 'nome' => 'Task 1', 'usuario_id' => 1)
            )
        ),
        array(
            'Usuario' => array('id' => 2, 'nome' => 'Usuario 2'),
            'Tarefa' => array(
            )
        ),
        array(
            'Usuario' => array('id' => 3, 'nome' => 'Usuario 3'),
            'Tarefa' => array(
            )
        ),
    )
*/
 
$this->Usuario->superFind('all', array('conditions' => array('Tarefa.nome' => 'Tarefa 1')));
/* Retorna:
    array(
        array(
            'Usuario' => array('id' => 1, 'nome' => 'Usuario 1'),
            'Tarefa' => array(
                array('id' => 1, 'nome' => 'Tarefa 1', 'usuario_id' => 1)
            )
        )
    )
*/

Em resumo, no Containable ele listou todos os usuários e no relacionamento Tarefa veio apenas os que tinham a ‘Tarefa 1′. Já no SuperFind ele mostrou apenas os usuários que tinham a ‘Tarefa 1′.

O mesmo funciona com relacionamentos HABTM. Para os relacionamentos hasOne e belongsTo não são necessários, pois isto já funciona nativamente.

Por enquanto é possível fazer isto apenas com um nível de filtro, ou seja, você não poderá colocar nas condições algo como Tarefa.Projeto.nome.

Bem, por enquanto é isso. Alguém tem mais sugestões do que poderia entrar? O que sente falta no find?

Abraços e bom uso.

Uma pequena correção de segurança também foi feita nesta versão. Este problema de segurança afeta apenas os sistemas que utilizam o modo debug em produção. Caso deseja apenas corrigir o problema de segurança, sem atualizar o core inteiro, você pode aplicar o patch disponibilzado por eles em http://bin.cakephp.org/view/1459556460.

A nova versão (1.2.7) está disponível no GitHub. A lista completa das alterações pode ser vista no Changelog.

Lembro também que está previsto para domingo o lançamento da versão 1.3.0-RC5! Vamos aguardar pra ver.

Estava aqui implementando alguns projetos e vi o quão chato é ter que implementar os models no cake sempre pensando nas queries que ele irá gerar.

As vezes vou fazer um find em models que tenham hasMany e quero fazer um filtro pelo model do hasMany e não consigo. Se eu coloco no conditions ele diz que a tabela do hasMany não existe. Se eu uso Containable ele mostra todos os registros do model que fiz o find com alguns tendo associações vazias. Ou seja, ele não faz JOIN com as tabelas hasMany nesses casos, sempre gerar queries diferentes e não sabe tratar direito.

Pensei em implementar isto no core do cake e propor para eles, mas a release 1.3 está fechada para enhancements, então ficaria para a versão 1.4/2.0 que sabe-se lá quando vem… Pensei então em um plugin para implementar isto, mas aí entra meu maior problema em computação: qual o nome?!

Alguém tem alguma sugestão? Como será um projeto a nível internacional, pensei em “SuperFind”, “FindPlusPlus”, “xFind”… Alguém tem alguma melhor?

No começo será mais para melhorar os relacionamentos de joins e afins, mas futuramente trabalhar melhor um pouco os casos de limit nos relacionamentos e outras coisitas a mais do find.

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.

Mais informações podem ser vistas em http://bakery.cakephp.org/articles/view/rc4-close.

Estava pensando sobre o desenvolvimento de um sistema modular (um ERP, CRM, etc), vendido em partes para o cliente e que o código fosse deixado no cliente (nem que fosse criptografado com as diversas ferramentas que há disponível por aí…). Dai pensei, como fazer isso com o CakePHP?!

Pensando, achei que fosse legal criar cada módulo como um plugin, inclusive alguns recursos básicos do sistema, como a parte de autenticação (login). Deixar a ‘app’ como um barramento da aplicação, fornecendo components, helpers, layouts, css/js, vendors, etc. Essa parte funcionaria como uma infra estrutura do sistema, onde as rotas poderiam ser criadas dinâmicamente pelo AppController do plugin ou usar as rotas diretamente do sistema (plugin/controller/action/params).

Hoje o CakePHP dispões de várias funções para identificar se o app possui um componente ou outro plugin instalado, podendo os plugins “se conversarem”. O comando App::listObjects(‘Plugin’), por exemplo é fantástico para saber se um outro módulo também está instalado. Assim não precisaria cadastrar cada módulo numa base de dados, que poderia ser manipulada pelo cliente ou coisa do genero.

O mesmo poderia ser aplicado a uma empresa que possui diversos softwares, não necessariamente inteligados (em módulos). Onde todas as aplicações teriam um ambiente de desenvolvimento comum (barramento) e cada aplicação seria um plugin. Isso reduziria a quantidade de código e, consequentemente, o tamanho da aplicação nos clientes que tiverem mais de uma aplicação.

O que acham? Já passaram por algo assim?

Para solucionar o caso, achei que o melhor jeito seria criando uma classe de View nova. A classe View do CakePHP ela sempre procura um arquivo de view, além do template. Com a nova classe, seria feita a renderização ali mesmo, sem a necessidade de novos arquivos.

A classe que criei (JsonView) pode ser baixada aqui. Ela deve ser colocada na pasta views de da sua aplicação (nenhuma sub-pasta) com o nome de json.php. Ou seja, no final, você terá o caminho app/views/json.php.
Como Usar

Para usar é bem simples. No seu controller, quando você for retornar um código em JSON, basta alterar a variável $view do controller para usar a nova classe. Além disso, os dados que você quer que retorne, devem ser setados com o nome ‘json‘ no seu controller. Caso não seja, ele vai renderizar normalmente. Exemplo de uso no controller:

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

class UsuariosController extends AppController {
	var $uses = array('Usuario', 'Grupo');
 
	function index($json = false) {
		$this->set('usuarios', $this->Usuario->find('list'));
		if ($json) {
			$this->view = 'Json';
			$this->set('json', 'usuarios');
		}
	}
 
	function multilista($json = false) {
		$this->set('usuarios', $this->Usuario->find('list'));
		$this->set('grupos', $this->Grupo->find('list'));
		if ($json) {
			$this->view = 'Json';
			$this->set('json', array('usuarios', 'grupos'));
		}
	}
}

Neste caso, quando o parâmetro de index não for true, ele vai renderizar como se fosse uma requisição normal. Caso passe como true, ele irá renderizar como JSON. Já no método multilista, além do parâmetro para verificar se é JSON, ele passa um array de variáveis para a view JSON, assim a classe irá renderizar mais de uma variável.

Outra maneira de se fazer é definir a variável $view da classe diretamente com ‘Json’ (assim como foi feito com $uses no exemplo). Assim, sempre que você der um set na variável ‘json’, a classe da View se liga e renderiza em json, caso contrário mantém o normal.

Conclusão

Este é um método fácil e rápido de renderizar as requisições JSON, sem precisar criar um arquivo para cada requisição e sem precisar de muito código (tanto no controller, quanto na view).

O código que fiz, é compatível com PHP 4 e 5, então é possível usar com o CakePHP sem medo em qualquer versão de PHP.

Abraços e bom uso. Dicas são sempre bem vindas.

Saiu hoje a nova versão do CakePHP 1.2, através da release candidate (RC) 1, usando a revisão 7119.

As maiores alterações são alterações no modo de utilizar as condições e colocar vários métodos em desuso.

Para quem quiser mais informações sobre o lançamento, consulte o link oficial (no Bakery). Quem quiser fazer o download agora, clique aqui.

Abraços e bom uso para todos.