Mas o objetivo deste post não é dizer o que já foi dito, quero iniciar uma série de posts onde vou explicar o funcionamento de alguns recursos dentro do Comitiva, convidando todos os desenvolvedores a opinar sobre implementação e contribuir com o projeto.

O assunto de hoje é controle de acesso, então vamos ao que interessa.

Como funciona o controle de acesso no Comitiva?

Utilizamos o componente Auth do CakePHP para cuidar da autenticação (efetuar login, verificar se o usuário está logado e efetuar logout).
Mas precisávamos ir um pouco além da configuração básica, definindo diferentes opções para diferentes tipos de usuários. Para isso, consideramos duas opções iniciais: usar também o Acl Behavior ou ficar apenas com o AuthComponent e criar diferentes actions para diferentes tipos de usuários.

Como possuímos apenas dois tipos de usuários (admin e participant) decidimos pela que seria mais simples inicialmente – mesmo sabendo que a manutenção no futuro poderia ser mais complicada – que foi criar diferentes actions para os tipos de usuários.

Para criar essa funcionalidade, definimos inicialmente um prefixo para cada tipo de usuário (prefixos ‘admin‘ e ‘participant‘). Em seguida configuramos o AuthComponent desta maneira (código extraído do AppController):

//Configure AuthComponent
$this->Auth->authorize = 'controller';
 
if( !isset($this->params['prefix']) || !( in_array($this->params['prefix'], Configure::read('Routing.prefixes')) ) )
{
	// all non-prefixed actions are allowed
	$this->Auth->allow('*');
}

Ou seja, toda ação que não tiver prefixo ou o prefixo não estiver definido nas configurações de rota serão públicas (assim é possível, por exemplo, deixar uma página com instruções acessível à qualquer usuário).

Mas como fica essa verificação de tipos no controlador? Como definimos o método de autorização do Auth como ‘controller’, precisamos definir em todos os controladores o método isAuthorized que deve retornar true quando o acesso é aprovado e false caso contrário.
Seguindo a ideia de que cada tipo de usuário possui um prefixo próprio nas ações, nosso método isAuthorized fica desta forma:

if($this->userLogged == TRUE && $this->params['prefix'] == User::get('type'))
{
	return true;
}
 
return false;

Onde o atributo $this->userLogged pertence a classe AppController e sua função é reduzir chamada ao método $Auth->login() e na segunda parte da condição temos uma comparação entre o prefixo da url acessada e o tipo do usuário – se ambos forem iguais, então o acesso está liberado.

Por fim, devemos criar nossas ações para cada tipo de usuário, onde o prefixo será usado para validar o acesso à aquela ação, veja o exemplo da ação “listar pagamentos”:

// ação exclusiva para admin - tem acesso aos pagamentos de todos os outros usuários
public function admin_index($event_id = null)
{
	$this->Subscription->recursive = 0;
 
	if(is_numeric($event_id))
	{
		$this->paginate = array(
			'conditions' => array(
				'event_id' => $event_id
			)
		);
	}
 
	$this->set(compact('event_id'));
	$this->set('subscriptions', $this->paginate());
}
 
// ação exclusiva para participant - tem acesso somente aos próprios pagamentos
public function participant_index()
{
	$this->Subscription->recursive = 0;
	$this->set('subscriptions', $this->paginate(array('user_id' => User::get('id'))));
}

Como podem ver, isso permite a criação de diferentes regras de negócio para os diferentes tipos de usuários e embora aumente a quantidade de código “redundante” por repetir alguns procedimentos para todos os tipos de usuários, a leitura e entendimento do código é facilitada – basta ver o prefixo do método (ação) para saber quem terá acesso a ele.

Bom, a conclusão que tirei do comparativo foi de que a velocidade de execução é importante, mas mais do que isso, o programador é essencial. No exemplo da thread supracitada, o PHP perdia feio para as outras linguagens, mas olhando para o código escrito em PHP, dava para notar  vários erros de uso da linguagem e suas funções (ponto para o Begnini que viu o código antes de todos).

Então a dica de hoje é: estude bem a linguagem. Procure a saber o funcionamento das funções e construções da linguagem, isso é essencial para se tornar um bom programador.

Exemplos de código

//uso comum
for($i = 0; count($var) < 0; $i++)
  ...
 
//forma mais adequada
for($i = 0, $c = count($var); $c < 0; ++$i)
 ...
 
//outro caso, ao invés de forçar várias verificações
if( $a > 100 )
 ...
if( $a < 100 )
 ...
if( $a == 100 )
 
//use a estrutura adequada
if( $a > 100 )
 ...
else if( $a < 100 )
 ...
else //não precisa fazer o último teste
 ...
 
// esse último caso que me inspirou a fazer o post
 
// a pessoa só queria saber se o array $var tava vazio, e para isso contou todos os seus elementos
if ( count($var) > 0 )
 ...
 
// enquanto ela poderia ter usado uma verificação direta como
if ( !empty($var) )

Este último caso, que motivou o post foi visto no changelog da versão 1.2.6 do CakePHP. Neste caso o “erro” foi encontrado e corrigido pelo brasileiro Juan Basso neste commit.

O intuito do post não é meter o dedo na cara de ninguém, apenas alertar para situações onde culpamos uma determinada linguagem pelo desempenho de nossa aplicação quando o problema na verdade é o mal uso que estamos fazendo.

Tenho feito alguns testes em cima dele, estou inclusive reescrevendo um pequeno CMS que possuímos na empresa em cima desta versão (árvore 1.3-dev do repositório do projeto) e apesar de alguns pequenos bugs (ainda é uma versão de desenvolvimento, né?) esta versão possui muitas melhorias na sintaxe – que agora está mais concisa –  e novas funcionalidades.

Para a migração de nossa aplicação, não foi preciso alterar muita coisa, porém para grandes aplicações, deve-se considerar a necessidade do upgrade.

Abaixo segue uma lista de links para algumas páginas com informações sobre esta nova versão do CakePHP (todas em inglês):

• Lista de TODO (tudo que já foi realizado está riscado)
• Novas features
• Guia de migração (upgrade de aplicação feita com o CakePHP 1.2 para 1.3)

Caso tenha interesse em ajudar os desenvolvedores, baixe a versão em desenvolvimento e faça alguns testes. Só não esqueça de reportar eventuais problemas ou patchs que você venha a produzir. Não se preocupem com o tempo de resposta da equipe de desenvolvimento, eles realmente estão empenhados em fazer um bom trabalho, é possível que tenha feedback de seu ticket/patch em menos de 1 hora – experiência própria.

Logo que concluir algumas tarefas e tiver feito mais testes colocarei aqui meu “parecer” sobre a nova versão, enquanto isso acompanhe a página de desenvolvimento para ficar por dentro das atualizações.

Acontece que quem trabalha com Drupal, Joomla! ou CakePHP (última  versão estável é a 1.2) deve aguardar ainda para poder utilizar a versão 5.3 do PHP, que incluí várias mudanças, caso contrário eles podem não funcionar ou apresentar vários avisos.

Pesquisando sobre o problema descobri que não há no repositório do OpenSUSE (os oficiais nem nos mais conhecidos) o PHP 5.2 disponível, então como fazer? Baixar o fonte e compila-lo? É uma saída, mas queria algo “OpenSUSU-like” (mais fácil).

Dando uma vasculhada no oráculo encontrei openSUSE 11.2: Downgrade PHP 5.3 to 5.2

Resolvi adaptar algumas coisas e funcionou perfeitamente, vamos lá aos passos com minhas modificações:

1. Abra o Gerenciador de Software;
2. Vá no menu “Configuração” -> “Repositórios”;
3. Procure o repositório “Atualizações Para o OpenSUSE 11.2-0″, clique sobre ele e depois no botão editar, na parte inferior da janela;
4. No campo “Diretório do Servidor” altere o “11.2″ para “11.1″ e então clique em OK; Na versão 11.1 o PHP está na versão 5.2
5. Procure o repositório “OpenSUSE 11.2 OSS”, clique sobre ele e depois no botão editar; Este e o próximo passo são necessário caso você deseje fazer o downgrade do MySQL para versão 5.0 (eu recomendo isso para deixar tudo compatível, como era no OpenSUSE 11.1)
6. No campo “Diretório do Servidor” altere o “11.2″ para “11.1″ e então clique em OK;
7. Novamente clique em OK na listagem de repositórios;
8. De volta a janela de gerenciamento de software, pesquise por PHP5, caso você já tenha instalado o PHP 5.3 aproveite agora para remover tudo relativo a ele, caso contrário selecione os pacotes que precisar e tenha certeza de marcar a versão correta (para mim foi 5.2.11). Verifique a versão de cada pacote clicando sobre ele e em seguida na aba “Versões” da janela, se houver mais de uma, marque a relativa ao PHP 5.2.x (onde x for o maior disponível);
9. Agora, pesquise os pacotes relativos ao MySQL (utilize o termo “mysql” na caixa de busca);
10. Você deve marcar as opções “libmysqlclient15″, “mysql” e “mysqlclient” conferindo se todos estão com a versão selecionada para 5.0.x (onde x é o maior número disponível);
11. Clique agora em OK para instalar os pacotes, uma janela irá abrir informando a necessidade de instalar alguma dependência. Dê uma olhada se não há conflitos e clique em OK; Agora é só aguardar.
12. Abra agora o “Repositórios de Software” e volte os repositórios para sua configuração original (trocando o 11.1 para 11.2), caso contrário não receberá as últimas atualizações dos outros softwares. Recomendo também que vá ao “Gerenciador de Software” e bloqueie os pacotes que instalou, para que o OpenSUSE não tente atualiza-los (os pacotes do PHP e MySQL);
13. Depois de instalar os pacotes, reinicie seu Apache logando-se como root no terminal e executando o comando “rcapache2 restart”; Verifique se o PHP está funcionando corretamente. Deve estar;
14. No OpenSUSE 11.2 o socket do MySQL mudou de endereço, mas como instalamos a versão antiga do MySQL não teremos essa alteração, porém alguns aplicativos (além do PHP) usam o MySQL (como o meu Amarok), então vamos criar um link simbólico onde deveria ser o endereço novo apontando para o antigo para que não haja problema, faremos isso como root;
15. Crie o diretório que é padrão para o socket na versão 11.2 do OpenSUSE: mkdir /var/run/mysql
16. Entre no diretório criado e crie o link simbólico para o socket: ln -s mysql.sock /var/lib/mysql/mysql.sock
17. Reinicie seu OpenSUSE e bom proveito.

Caso tenha alguma dúvida deixe-a nos comentários. Se necessário tiro alguns screenshots para ilustrar melhor.

Tenho andado bem corrido ultimamente e não tenho conseguido dar a atenção que queria ao blog. De agora em diante as coisas não devem melhorar muito, mas farei o possível para trazer coisas interessantes pra cá.

Desde o dia 21/10/2009 estou em Foz do Iguaçu – PR, para participar do Latinoware 2009, um dos maiores eventos de software livre das Américas.
Estou tendo a oportunidade de ministrar um minicurso e apresentar uma palestra no “subevento” COLAPHP – Congresso Latinoamericano de PHP, que possui uma trilha dedicada a linguagem dentro do  Latinoware.

A experiência não poderia estar sendo melhor. Pude conhecer excelentes profissionais e fazer muitas amizades.

—————– fim do rascunho 1 ——————-

Nos dias 23 e 24 de outubro tive a oportunidade de ministrar um minicurso e uma palestra dentro da trilha COLAPHP do Latinoware.

Ambos tratavam do CakePHP, no caso do minicurso fizemos uma introdução no framework, falando um pouco de seu funcionamento, suas convenções e criamos rapidamente uma aplicação simples utilizando o terminal com o Bake.

O slides utilizado no minicurso foi este:

No caso da palestra, falei novamente sobre a integração de aplicações escritas em CakePHP e Flex, dando uma revisada na apresentação. Ela ficou assim:

Aproveito o espaço (e a disponibilidade de tempo) para agradecer todos que participaram do evento como um todo, seja na organização, apoio ou assistindo, perguntando, corrigindo e ajudando a gente durante as apresentações. Obrigado a todos.

—————- fim do rascunho 2 ——————-

O texto do rascunho 1 foi escrito em 23/10/2009, o do rascunho 2 logo após o evento, hoje é 16/01/2010 e o textos ainda estevam como rascunho para ser publicado no blog. Pois é, esse final de ano foi realmente muito corrido, mas valeu a pena.

Agora é hora de se organizar para poder ter um 2010 ainda mais proveitoso (de começo ele já está sendo muito melhor).

Até breve.

Tivemos público maior do que o esperado, e todos muito participativos, a quantidade de empresas apoiando também foi grande – principalmente se pegarmos como referência outros eventos de Campo Grande. O nível das apresentações também estavam muito bem definido. Enfim, se melhorasse era perigoso estragar.

Passei a última semana inteira preparando minha apresentação no workshop, inclusive quase não durmi essa noite (3 horas exatas), mas no final tudo aconteceu dentro dos conformes. A participação dos presentes foi outro ponto que me chamou a atenção, serviu para provar que quem estava ali realmente sabia o que estava fazendo ali.

Quero aproveeitar mais uma vez para agradecer a todos que ajudaram de alguma forma no evento: organizadores e amigos (porkaria, zehzinho, Leonardo), o sempre disposto palestrante e amigo Raphael (raphox), aos apoiadores, aos patrocinadores e claro, a todos os presentes que acreditaram no evento e compareceram mesmo com o tempo ruim.

Para quem foi ao evento e gostaria de ver a apresentação de slides que utilizei, ela está acessível pelo endereço: http://www.slideshare.net/cauancabral/php-flex
Na apresentação falei sobre a utilização de Flex para construção de RIA’s juntamente com PHP (mais especificamente utilizando o framework  CakePHP), o exemplo da palestra pode ser encontrado no repositório svn: http://svn.radig.com.br/pagode – na data da  palestra a versão utilizada foi a #3, o sistema será complementado até que se torne realmente um sistema de controle financeiro pessoal. Portanto se tiver interesse no mesmo, acompanhe aqui no blog as novidades do projeto.

———-

O Raphox e o Porkaria também liberaram os slides das palestras, veja aqui e aqui respectivamente.

Habilitar a internacionalização e ter a localização em uma aplicação com CakePHP desde a versão 1.2  é relativamente simples: basta uma lida no nosso Cookbook e pronto.

Outra coisa que é relativamente simples de se fazer é validar os dados, basta termos um atributo em nosso modelo chamado “validate” e seguir as dicas do livro de receitas.

Mas pelo Cookbook somos induzidos a fornecer a mensagem de erro na hora de criar a View, algo que eu particularmente não gosto. É até comum termos um modelo que é usado por Controllers diferentes e consequêntemente por Views diferentes.

Uma maneira de evitar isso, é definir as mensagens de erro já na definição das regras de validação, dentro do atributo “validate” do seu modelo. O grande problema é que para traduzir uma determinada expressão utilizamos um método, e a chamada de método na definição estática de um atributo não é permitida no PHP (dúvida? tente fazer o código abaixo)

class Modelo extends AppModel {
var $validate = _('ola mundo');
}
//esse código não devera ser executado

A solução para isso é a atribuição das regras de validação no momento da instanciação da classe, ou seja, no seu método construtor, da seguinte maneira

 class Modelo extends AppModel {
var $validate;
function __construct(){
parent::__construct();
$this->validate = array( /* aqui você pode definir as regras e mensagens,mesmo chamando um método */ );
}
}

Qualquer dúvida não deixem de utilizar os comentários ;]

——–
Atualizado: havia esquecido da chamada ao construtor da superclasse AppModels ( através do parent::__construct() ) no último código mostrado.
——–
Atualizado

Obrigado ao José Tranca e Thiago Goulart pelos comentários, as soluções propostas por eles devem ser adotada em detrimento da minha, já que melhora consideravelmente a modularidade e reusabilidade das traduções.

Desde que descobri o CakePHP faço parte do grupo CakePHP Tuga e ocasionalmente no canal de IRC do grupo #cakephp-pt na rede Freenode.org, e já tive a oportunidade de aprender e ajudar diversas vezes.

Vamos as dúvidas:

1. Como salvar dados de um formulário que envolva um relacionamenteo de “muitos para muitos”/many-to- many ou ainda de HasAndBelongToMany (HABTM) ?

Nesta dúvida temos que ter em mente que o CakePHP faz todas as ligações entre nossos modelos desde que sigamos suas convenções, caso façamos isso, não haverá dificuldades.
Mas quais são essas convenções? Veja você mesmo.

Um detalhe que não podemos esquecer é que por padrão o CakePHP está preparado para tratar suas convenções em inglês, então, se não quisermos ter de modificar as configurações padrões, temos de desenvolver em inglês. Ok?

Seguindo todas as conveções o que fica faltando? É preciso saber como um relacionamento HABTM se manifesta em um formulário, ou seja, como ele é apresentado. No CookBook temos um texto sobre o caso. Resumindo, o que temos de ter é:

• Um formulário com o nome de um dos modelos envolvidos no relacionamento. Por exemplo, em um blog temos um modelo Post e outro Tags, os dois estão ligados por um HABTM, então no formulário para inserir um Post, o nome de formulário seria Post.
• Um ou mais campos identificados com o outro modelo parte do relacionamento e sua chave. No nosso exemplo seriam um ou mais campos com o nome ‘Tag.Tag’.

No item anterior que surge a principal dúvida: como definir o nome do meu campo? que tipo de campo usar?

Primeiro definimos o tipo de campo a se utilizar: normalmente utilizamos um Select box para multiplas seleções OU um conjunto de Checkbox. Qualquer que seja a escolha o restante é bem simples:

/*
$tag é o retorno de um find('list') com os campos id e name selecionados
$tags = array( array('id' => 1, 'name' => 'tag 1'), array('id' => 2, 'name' => 'tag 2') );
 
o índice 'multiple' só deve ser utilizado quando quiser um conjunto de checkbox
*/
echo $form->input('Tag.Tag', array(
	'type' => 'select',
	'multiple' => 'checkbox',
	'options' => $tags,
	'labels' => 'Selecione as tags'
	));

Com isso seu formulário já retornará o que é esperado pelo CakePHP e tudo que será necessário para salvar os dados do relacionamento é utilizar o método ‘saveAll’ ao invés de ‘save’.

Ainda esta semana comentarei das dúvidas sobre validação.

E apesar do PHP fornecer centenas de funções prontas para diversas tarefas rotineiras, ele perde feio comparado a outras linguagens mais novas como Ruby ou Python, principalmente quando juntamos a estas seus grandes frameworks – Rails no caso do Ruby e Django no caso do Python.

Mas a comunidade PHP tem suas cartas na manga, vários frameworks agilizam o desenvolvimento tanto em aplicações simples como em aplicações sofisticadas.
E são várias as opções. Tem para todos os gostos, nos próximo posts vou falar um pouco deles.

Hoje começo com o CakePHP:

Descrição:
Compete de frente com o Rails. Possui uma base bem estruturada, código bem organizado, comunidade participativa e uma licensa flexivel. Seu grande destaque está no baker, que gera ações básicas (criar,ler,atualizar e apagar entradas) para uma tabela do banco de dados.

Como usa-lo?
É muito fácil, basta ir a página dele e fazer o download do último lançamento. Recomendo a versão 1.2.xx , apesar de ser RC2 (candidata a estável) ela já está bem estável e possui vários melhoramentos em relação a versão 1.1.xx.
Em seguida descompacte o arquivo onde achar melhor (dentro de seu servidor web) e pronto. Agora só falta você configurar o arquivo “/app/config/database.php”. Nele você encontra instruções de como inserir as informações para acessar o seu banco de dados, há até um exemplo de como fazer.
Agora é só acessar, através do navegador, a pasta que você descompactou o CakePHP.

Onde encontrar material para estudo?
Como comentei antes, o CakePHP possui uma comunidade bem participativa, mas a maioria não fala português, então você encontrará bastante informação em inglês, aqui listo alguns sites e blogs com informações sobre o tema, bons estudos:

• CakePHP – A página oficial, sempre com novidades (inglês)
• The Cookbook – O manual oficial do cake. Possui conteúdo para versão 1.1 e 1.2, sendo que a segunda esta sendo finalizada. Obrigatório. (em inglês com parte do conteúdo em português, só alterar no rodapé da página).
• API for CakePHP – A documentação das classes, métodos e funcionalidades do CakePHP. Não é muito rica em detalhes, mas está melhorando. Obrigatório. (inglês)
• lemoncake – Um blog com várias discussões sobre CakePHP e dicas/tutoriais de como usar recursos do Cake. Muito recomendado. (inglês).
• aranworld – Um blog que tem posts esporádicos a respeito do CakePHP, mas no link que vinculei, há uma série de posts sobre o sistema de controle de acesso do CakePHP, uma ferramente extremamente poderosa mas que pode parecer complicada de utilizar no inicio. Muito recomendado. (inglês)
• CakePHP – Brasil – Portal brasileiro sobre CakePHP, ótimo para quem não arrisca muito o inglês, possui dicas e até uma versão traduzida do manual. Muito recomendado. (português)

E podem esperar que em breve haverá vários posts a respeito. Estou utilizando bastante o CakePHP e tenho gostado muito. Colocarei algumas dicas aqui logo logo.