No trabalho as coisas finalmente ficaram interessantes de umas semanas pra cá. Me tornei o responsável pelo novo sistema de controle de agrotóxicos do Estado. Faço parte da comissão responsável pela migração do novo site do Instituto e sou o responsável “suplente” nos sistemas de controle da água e do ar. Não que isso signifique alguma coisa, mas já acumulei mais horas em reuniões nos últimos dois meses do que em todos os outros trabalhos anteriores. :P

Tenho sentido falta de programar. O mimimi da vez é que quando tenho tempo, falta disposição. Quando tenho disposição, falta tempo. :/ Mas hoje consegui juntar ambos e dei uma brincada. Baixei o novo Zend Studio e aproveitei para dar mais uma testada na Zend Framework. E definitivamente, não rola. ô bagulho totalmente desnecessariamente complexo. Ainda mais quando se conhece o CakePHP.

O pior, pra mim, é que no tal “guia rápido em 30 minutos” do site oficial, está escrito o seguinte:

While Zend Framework is itself configurationless, you often need to configure your application.

Com isso eu entendo que a framework deveria ser plug-n-play e eu só configuraria coisas que não são padrão ou que eu mesmo quisesse diferente (CakePHP? Oi?). No entanto, 30 minutos eu perdi somente configurando o básico da framework, isso enquanto seguia o próprio tutorial, e não sozinho, no chute. E olha que o Zend Studio cria toda a estrutura básica e arquivos de configuração e controllers básicos. Sem falar na burocracia orientada a objetos para se criar uma simples conexão com o banco de dados (que não funcionou, diga-se).

Enfim, CakePHP it is. Vou voltar a fazer umas paradas, brincar com o SimpleTest, HTML5, CSS3, tentar ser mais ativo no grupo PHP Rio… vamos ver no que dá! :D

Nenhum post relacionado.

Há umas semanas atrás eu estava configurando a framework pra um projeto que vou fazer com a Bruna e tive alguns problemas com esse componente. Ele faz muito mais do que eu preciso e de uma forma que não me agrada muito: não me deixando no controle do que acontece.

Então comecei a desenvolver um componente pra fazer exatamente que eu quero, ou seja, definir quais páginas serão acessíveis por usuários deslogados. E só.

Com 110 linhas de códigos, incluindo linhas em branco e comentários inúteis, ele está funcionando e me atendendo até agora. Vou dar mais um tempo, usar mais um pouco, ver se não to esquecendo de nada, quando estiver mais maduro, disponibilizo aqui.

Nenhum post relacionado.

Como tenho preguiça de fazer coisas que certamente já foram feitas e até melhor que eu faria, resolvi procurar o arquivo pronto. E encontrei na pasta do Gabriel no Github. Não sei qual a frequencia de atualização nem se contem muitos erros, mas se tiver algum, atualizar é moleza, basta olhar o arquivo que dá pra entender a lógica.

Nenhum post relacionado.

Ontem e hoje eu passei o dia desenvolvendo uma pequena aplicação com o CakePHP. Foi a primeira que eu efetivamente concluí. :P

Esses dias, houve uma grande promoção de CDs na Submarino, no meio de tanto cd interessante, deixei de comprar alguns simplesmente pq eu não lembrava se eu já tinha ou não. Por mais bizarro que isso possa ser para alguns, eu costumo não lembrar os cds que tenho. :P Então ele basicamente me diz isso e pronto, acabou.

Desenvolver com o Cake foi bem tranquilo, continuo não me agradando do Form Helper, mas o utilizei da mesma forma. Primeiro fiz a parte de programação, comecei ontem depois do almoço e terminei ontem mesmo. Hoje passei o dia todo somente fazendo o layout. :O

Obviamente esse “projeto” não é aberto ao público, uma vez que o fiz somente para controlar meus CDs, mas quem sabe não vai rolando uns upgrades no futuro? ;P

Posts Relacionados:

1. Updates

Por exemplo, vamos criar um formulário com o campo username e brincar com ele. Basicamente, seria um formulário para cadastrar usernames em um sistema. Na view add.ctp temos o seguinte código:

echo $form->create('User');
echo $form->input('username');
echo $form->end('Save');

Ele vai gerar o seguinte HTML no navegador:

<div class="input text">
   <label for="UserUsername">Username</label>
<input id="UserUsername" maxlength="25" name="data[User][username]" type="text" /></div>

Se eu tiver algum erro na validação dos dados (feitos no model), a mensagem de erro será exibida abaixo no input.

<div class="input text">
   <label for="UserUsername">Username</label>
<input id="UserUsername" maxlength="25" name="data[User][username]" type="text" />
<div class="error-message">Username required!</div>
</div>

Mas, e se eu quiser essa mensagem de erro em outro lugar? Em cima do input, por exemplo? E se eu não quiser esse label? Supondo que eu queira exibir somente o input e a mensgem de erro em cima dela, tenho que fazer o seguinte:

echo $form->error('username');
echo $form->input('username', array('label'=>false, 'div'=>false, 'error'=>false));

Coloco a mensagem de erro onde eu quiser através do método error. Depois oculto as tags que não quero na criação do input. A div estou ocultando por causa da semântica, senão a mensagem de erro ficaria do lado de fora da div que contém o input. Estou setando o error do input como false pq senão além dele exibir a mensagem através do método error, ele também ira criar a div com o erro embaixo do input, ficando assim duas mensagens.

Deve ter uma solução melhor para casos assim, mas como não encontrei nada na minha pesquisa, tive que dar meu jeito.

Nenhum post relacionado.

O primeiro passo seria criar um arquivo, por exemplo, dbo_sem_bd.php na pasta app/models/datasources/dbo/ com o seguinte código:

1
2
3
4
5
6
7
8
9
10

class DboSemBd extends DboSource {
   function connect() {
      $this->connected = true;
      return $this->connected;
   }
   function disconnect() {
      $this->connected = false;
      return !$this->connected;
   }
}

Depois, bastava alterar o arquivo database.php na pasta app/config e dizer que o driver utilizado nas conexões será o sem_db. E pra finalizar com chave de outro, em cada model do sistema, setar a variável $useTable como FALSE.

Eu sinceramente prefiro criar um banco de dados vazio e deixar pra lá, mas o que me deixa mais espantado é o fato de uma ferramenta tão cheia de recursos quanto o CakePHP não tenha uma opção onde eu possa colocar que não vou utilizar um banco de dados.

Uma outra “solução”, e aqui posso estar falando besteira já que não vi isso a fundo, seria criar todas as páginas dentro da pasta pages. Mas ai eu teria que criar rotas para todos os meus arquivos para não ter que chamar sempre esse controller (pages) na url. Isso também geraria um trabalho tosco.

Nenhum post relacionado.

Quer dizer, o exemplo do conceito sendo explicado utilizando os personagens d’O Senhor dos Anéis é sensacional! Mas só serve pra isso mesmo, explicar o conceito. Por que na prática, a coisa é um pouco mais complexa.

Pra tentar entender o funcionamento, criei o blog de exemplo do próprio “Livro de Receitas” do CakePHP. Porém ele é simples demais e nem tem usuários. Então criei uma tabela para armazenar somente um login e senha de acesso. Nada muito difícil para quem já mexeu com o Cake pelo menos uma vez.

Aí vem outro problema: por padrão, o ACL vem pronto pra trabalhar com CRUD, e dificilmente teremos um sistema que só utilize os métodos do CRUD. O que fazer então? Depois de dias lendo documentação sobre o assunto, chegou até mim um texto (perdi o link, desculpem. :/) que dizia, resumidamente, que era só associar os actions como ACOs normalmente, e na hora de salvar no banco, dar acesso total nos

Então, supondo que esteja tudo pronto, vamos resolver o grande problema que encontrei nos blogs que li: Os métodos de criação dos AROs e dos ACOs, bem como seus relacionamentos, não devem ficar espalhados pela aplicação. Crie um arquivo PHP separado para executar somente quando você precisar popular o banco de dados com as informações de acesso.

Então vamos começar criando um pequeno script que cria os AROs do nosso “sistema”:

1
2
3
4
5
6
7
8
9
10

$aro = new aro();
$groups = array(
   0 => array( 'alias' => 'Admins' ),
   1 => array( 'alias' => 'Authors' ),
   2 => array( 'alias' => 'Spammers' )
   );
foreach( $groups as $group ) {
   $aro->create();
   $aro->save( $group );
}

Esse script vai gerar grupos de usuários do sistema. temos os administradores, os autores do blog e spammers, que são usuários que não terão acesso a nada.

Agora vamos criar alguns usuários:

1
2
3
4
5
6
7
8
9
10

$aro = new aro();
$users = array(
   0 => array( 'alias' => Pedro, 'parent_id' => 1 , 'model' => 'User', 'foreign_key' => 1 ),
   1 => array( 'alias' => Rafael, 'parent_id' => 2 , 'model' => 'User', 'foreign_key' => 2 ),
   2 => array( 'alias' => Adriana, 'parent_id' => 3 , 'model' => 'User', 'foreign_key' => 3 )
   );
foreach( $users as $user ) {
   $aro->create();
   $aro->save( $user );
}

Acima estou criando 3 usuários apenas, um para cada grupo. O campo parent_id aponta para o grupo que o usuário faz parte. O campo model, como o próprio nome diz, especifica um modelo. No caso, ele guarda o nome do modelo que o id armazenado em foreign_key pertence. Então no exemplo acima, o id do Pedro na tabela User é 1.

Agora vamos criar algumas ACOs:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$aco = new aco();
$group = array( 'alias' => 'Post' );
$aco->create();
$aco->save( $group );
$actions = array(
   0 => array( 'alias' => 'index' , 'parent_id' => 1 ),
   1 => array( 'alias' => 'view' , 'parent_id' => 1 ),
   2 => array( 'alias' => 'add' , 'parent_id' => 1 ),
   3 => array( 'alias' => 'delete' , 'parent_id' => 1 ),
   4 => array( 'alias' => 'edit' , 'parent_id' => 1 )
   );
foreach( $actions as $action ) {
   $aco->create();
   $aco->save( $action );
}

O processo para criação é exatamente o mesmo do utilizado no ARO. Aqui, primeiro criei um grupo com o nome do próprio controller, assim fica mais fácil organizar. Depois, criei uma ACO para cada action do controller e as relacionei com o grupo criado anteriormente.

Se você não definir nenhum tipo de permissão de acesso, por padrão, é tudo negado. Então vamos definir algumas permissões:

1
2
3
4

$this->Acl->allow( 'Admins' , 'Post' , '*' );
$this->Acl->allow( 'Authors' , 'Post' , '*' );
$this->Acl->deny( 'Authors' , 'Post/delete' , '*' );
$this->Acl->deny( 'Spammers' , 'Post' , '*' );

Na primeira linha, dei acesso total à todas as actions do controller Post para os usuários que fizerem parte do grupo Admins. Na segunda linha, dei acesso total também aos autores do blog, mas na terceira eu tirei a permissão deles de deletar algum post, ou seja, eles podem tudo, menos deletar o texto que escreveram. Assim é mais fácil do que ficar fazendo um allow para cada action do controller. Na quarta linha tirei a permissão de acesso à todas as actions do controller para quem for do grupo spammers.

Para verificar quem tem acesso ou não, dentro do seu controller, no método beforeFilter por exemplo, basta fazer o seguinte:

1

$this->Acl->check( 'Authors' , 'Post/delete' )

No nosso caso vai retornar FALSE.

Basicamente é isso. Tem outras coisas interessantes para se trabalhar junto com o ACL, como o ACLBehavior e o ACL Management Plugin. Uma boa leitura que pode ajudar um bocado é esse tutorial de utilização que um cara fez pro caso dele, tem até um sitezinho de exemplo.

Nenhum post relacionado.