KISS - Keep it simple, stupid!

A maioria já deve saber que o CakePHP está com a versão 1.3 do framework em estado beta. Me recordo que a versão 1.2 do framework já era bem agradável quando estava em fase beta, e portanto decidi testar o que o CakePHP 1.3 tinha de novo. Fiz o download e fui direto para a página que contém a descrição das principais mudanças da versão 1.2 para a 1.3. Quando vi que ela tinha um tamanho um pouco grande decidi testar logo alguma aplicação que eu tinha funcionando na versão 1.2.

Para minha surpresa ela não exibiu nem a página inicial, e ao invés disso várias mensagens de erro foram mostradas. Então vi que era realmente necessário ler a extensa página. Durante a leitura percebi que diversas mudanças importantes ocorreram, e logo vi o porque da minha aplicação sequer funcionar. Como a leitura é um pouco extensa, decidi resumir as principais mudanças aqui. As novidades vão ficar para depois, porque também são várias.

Principais mudanças do CakePHP 1.3

• Adicionadas configurações específicas do config/core.php para quem utiliza o PHP 5.3
• O arquivo webroot/index.php foi alterado, e deve ser substituído em sua aplicação
• Recomenda-se que todos os métodos e classes deprecados não sejam mais utilizados
• Admin routes foram removidas por uma configuração mais geral, chamada routes prefix. O route prefix admin pode ser definido com a linha

  Configure::write('Routing.prefixes', array('admin'));

• O método de remoção no modelo agora é único,

  Model::delete()

• O Model teve os métodos métodos findAll(), findCount() e findNeighbours() removidos
• Os diretórios css, js e img foram removidos dos diretórios app/vendors e plugin/vendors e substituídos com os diretórios plugin e theme no webroot
• Somente a variável

  $title_for_layout

  poderá ser definida para o título da página, tanto no Controller quanto na View

• Deve-se selecionar o ponto da aplicação desejado para dump de sql quando o debug está definido para 2, utilizando a linha de código

  echo $this->element('sql_dump');

  em qualquer ponto da aplicação

• SessionHelper e SessionComponent não são mais carregados por padrão. Agora devem ser declarados como qualquer outro helper ou component. Para manter o comportamento antigo, adicione a declaração de helpers e components em seu AppController
• A função

  SessionComponent::setFlash()

  teve seu segundo parâmetro alterado para usar um element e não um layout. Para alterar sua aplicação primeiro mova seus layouts para a pasta de elements e renomeie a variável

  $content_for_layout

  para

  $message

• Não existe mais o nível 3 de debug
• PaginatorHelper agora produz a saída dos métodos

  prev(); next(); first(); last();

  englobada por

  <span>

  e não

  <div>

  para tornar a estilização mais fácil

• Os métodos

  dateTime(); year(); month(); day(); minute(); meridian(); select();

  do FormHelper não possuem mais o parâmetro

  $showEmpty

  , e agora utilizam

  $attributes['empty']

• FormHelper::submit()

  agora pode criar outros inputs além de type=submit. Para isso utilize a option type

• FormHelper::button()

  agora cria elementos button ao invés de inputs reset. Para criar inputs de reset, utilize

  FormHelper::submit()

  com o parâmetro option definindo ‘type’ => ‘reset’

• O método

  FormHelper::create()

  não cria mais elementos fieldset escondidos, agora substituídos por divs escondidas, o que ajuda na validação de HTML 4

• No HtmlHelper os métodos

  link(); para(); div(); tag()

  não pussuem mais o parâmetro

  $escape

  , que foi substituído por

  $options['escape']

  . Similarmente os métodos

  meta(); css()

  tiveram o parâmetro

  $inline

  substituído por

  $options['inline']

• Agora as chamadas a

  $session->flash()

  não são mais auto-exibidas, sendo necessário adicionar

  echo

  antes da chamada a função, como em qualquer método de helper

• JavascriptHelper e AjaxHelper estão deprecados, e agora deve-se utilizar o JsHelper em conjunto com o HtmlHelper.

  $javascript->link()

  agora é

  $javascript->codeBlock()

  é

  $html->scriptBlock()

Já deu para perceber que vai dar trabalho mudar algumas coisas. E essas são apenas as alterações que considerei mais importantes, na página de migração do 1.2 para o 1.3 está a lista completa. Verifique nessa se alguma mudança afeta as suas aplicações.

Pelas alterações deu para perceber que o framework está mais preocupado com a padronização do seu comportamento, de código, utilização de Web Standards e desempenho, questões que são sempre importantes.
Bom, é isso, espero ter ajudado. Na próxima vamos dar uma olhada nas novidades do Cake 1.3.

Apesar das melhorias introduzidas no HTMLHelper do CakePHP 1.2, sempre achei ridículo ele gerar marcação apenas em XHTML. Sempre preferi HTML, e me via engessado pelo CakePHP nesse aspecto.

Acredito que muitos passam por essa dificuldade quando estão trabalhando com o HTMLHelper e FormHelper do CakePHP. Uma das principais consequências disso, é que o código gerado na maioria das vezes não é válido, pois mistura tags HTML e XHTML.

Mas sempre imaginei que deveria haver um meio de contornar isso. Certa vez verifiquei que existia um método chamado docType no HTMLHelper, e que era possível definir HTML 4.01 com ele. Mas minha alegria logo acabou quando percebi que ele não alterava o comportamento do Helper para gerar tags HTML.

Finalmente, hoje acabei me deparando com uma alternativa. Cansado de mensagens de código inválido fiz uma leitura mais cuidadosa do manual do CakePHP e encontrei a página que diz como gerar tags HTML 4.01. A solução não é muito elegante, mas é uma alternativa presente no próprio framework.
Espero que a solução sirva para vocês também!

Update 1:Para quem estiver com preguiça de fazer o arquivo do zero, fiz um repositório no Github com o arquivo e algumas tags. Conforme for sentindo necessidade vou aumentar o conteúdo dele. Quem quiser colaborar, está convidado!

Update 2: Apliquei as sugestões do Juan Basso, agora um Helper está disponível para manter as tags HTML 4.01. Vejam a discussão abaixo. O link do Github contínua o mesmo. Mantive o arquivo anterior para quem preferir o método da documentação do Cake.

Na última sexta-feira, 17/04, participei como palestrante de uma das etapas do processo seletivo da Empresa Júnior de Computação (Cop-Jr) da Universidade Estadual de Londrina (UEL).
Para quem quiser ir direto para os downloads, use a âncora.

Durante três dias foram abordados os assuntos:

• Metodologia Ágil
• HTML/CSS
• PHP e CakePHP

Fui o palestrante do último dia, falando sobre PHP e CakePHP. Visto que o grupo de inscritos era em sua maioria do primeiro ano do curso de Ciência da Computação, o conteúdo dos slides é bem introdutório. Procurei focar em conceitos e boas práticas, já que eles ainda vão aprender a programar.
Como exemplo, desenvolvi o blog do tutorial do CakePHP, onde é possível mostrar vários conceitos para quem está começando. Logo depois disso o Lucas acabou com minha apresentação, mostrando o Scaffolding….
Assim não vale, os caras tem que sofrer pelo menos um pouco!

Espero que eles tenham aproveitado e aprendido, e peço para quem tiver sugestões enviar nos comentários.
E sejam bem vindos, novos padeiros!

A apresentação está no formato odp, pra quem não tiver o OpenOffice, segue o link para download.
Apresentação processo seletivo da Cop-Jr
Blog desenvolvido em PHP puro e CakePHP

Já tinha visto muitas vezes o João José reclamando que não tinha um gerenciador de plugins feito o do rails… Inclusive, havia até postado aqui no KISS uma idéia que tinha encontrado no blog @TheKeyBoard…

A idéia é bem interessante, porém existe apenas um repositório centralizado, que o próprio desenvolvedor mantém.

A partir disso, surgiram nossas primeiras divagações:

• Por que nao possibilitar que cada usuário possa manter seu próprio repositório?
• Podíamos possibilitar a criação de um script de instalação/desinstalação?
• E se existisse um jeito de especificar as dependencias, e elas serem automaticamente resolvidas?
• Pouts! Mas se eu não quizer manter um repositório só pra poder guardar um link pra um plugin?

Assim surgiu o Plugin Manager, que ainda está em fase de implementação… Mas creio eu que está completo o suficiente para ser usado, testado, e também para que novas idéias surjam, não só nossas, mas de todos aqueles que se interessarem pelo projeto.

Botando pra Quebrar

Dentro da pasta APP/plugins/ execute:

git clone git://github.com/lucius/plugin_manager.git

pronto!

cake/console/cake -app SUA_APLICACAO plugin

Agora é só seguir as instruções

É sempre bom lembrar que o projeto está hospedado no github e que qualquer pessoa que deseja fazer modificações pode ficar a vontade para tal…

Eu e o Lucas tinhamos um trabalho bem divertido: criar um shell do cake. Ate aí, nada de muito complicado, pois a tarefa que seria executada era bem simples. De fato, realizamos o trabalho rapidamente. Comecei a pensar e vi que o log que seria gerado, poderia ser estupidamente grande, e tinhamos um feedback ‘preto-e-branco’ e pouco intuitivo…

Sempre fui o “cara da interface gráfica, das coisas gays e bonitinhas” como diria o Rafael (o homem modo-texto), e não seria numa hora dessas que deixaria isso de lado. xD

Comecei a conversar com o João, comentando esse fato, esperando que ele tivesse uma ideia (mesmo que copiada de alguém =D). Para minha surpresa, ali estava: cake-db-migrations.

Tá bom… mas e daí? Muito interessante o que joelmoss tinha feito… Mas para formatar uma string grande, além de ser obrigado a criar um estilo, ainda tinha que ficar concatenando varias strings com e sem formatação.

$this->out('Teste de formatacao simples '.$this->_colorize('funcionando',NOME_DO_ESTILO).'!');

Mas poderia ser mais fácil… algo como TAGS seria ótimo! Bom, depois de algum tempo de meditação e trabalho, agora elas funcionam… e de forma bem simples!

$this->formattedOut('Teste de formatacao simples [fg=green]funcionando[/fg]!');

E a saída no shell:

Bom, vamos ao que realmente interessa.

COMO USAR?

Primeiro: entre a pasta ‘plugins’ da app e

git clone git://github.com/lucius/improved_cake_shell.git

Depois, na hora de criar o seu shell em APP/vendors/shells/, apenas importe o plugin e extenda sua classe da ImprovedCakeShell (ao invés do Shell normal). O resto funciona da mesma maneira:

<?php
App::import('Vendor', 'ImprovedCakeShell.ImprovedCakeShell');
 
class TestShell extends ImprovedCakeShell {
    function main() {
        $this->addStyle( array(
            'TEST' => array(
                'bg' => 'green',
                'fg' => 'black',
                's' => true
            )
        ));
 
        $this->formattedOut('[b]Teste[/b] de formatacao [TEST]funcionando[/TEST]!');
    }
}
?>

Vamos com calma! Posso criar estilos completos sem ter que ficar abrindo e fechando milhões de tags?
SIM! Basta apenas utilizar o método addStyle, como feito ali em cima.

E como prometido:

Para obter informações mais detalhadas a respeito do uso é só consultar o README, que segue junto com o plugin.

Pronto! Agora seus logs de console trazem feedback de maneira mais eficiente, visualizável e BONITA!

Somente para divulgação, o Renan Gonçalves está organizando um evento sobre CakePHP em São Paulo. Pelo que ele está diz no blog, o evento é diferenciado por tratar o CakePHP como o foco principal, contrapondo com as típicas apresentações de “Introdução ao CakePHP blábláblá” by Renan em eventos aleatórios.

Eu realmente não sei se conseguirei ir mas se a grana der estarei lá marcando presença! Só para completar o aviso, o Renam convocou todos que estão interessados pelo evento para escrever um comentário no blog dele, assim ele poderá mensurar um tamanho para o evento.

Deploy é sempre um problema sério. Estamos sempre buscando soluções que minimizem o trabalho manual na hora de subir os arquivos para o servidor e deixá-los prontos para produção.

Em um projeto que temos, utilizamos o próprio Git para fazer esta tarefa, afinal o repositório central já fica lá no servidor mesmo, nada mais óbvio.

Então sempre que temos uma versão que está estável para produção, nos logamos por ssh e mandamos um git pull no diretório onde fica o site. Geralmente o merge ocorre sem problemas e fica tudo atualizado. Mas o problema é que os arquivos de configuração sempre são substituidos, e toda vez o trabalho de consertar as configurações de banco, colocar o debug pra 0, entre outras coisinhas (que sempre passam desapercebidas) é feito à mão.

Hoje, depois de fazer isso pelo menos umas 3 vezes, me lembrei que o Git tem um comando que poderia servir perfeitamente pra evitar toda essa edição manual na hora do deploy. É o git stash.

Agora, antes de executar o git pull, eu digito git stash save “Salvando configurações de produção”; com isso o git guarda os arquivos modificados em um local “invisível”, e executa um git reset –hard, que retorna todos os arquivos à versão HEAD. Aí o diretório fica limpo para receber o merge sem problemas.

Depois que o git pull for completo, é só digitar git stash apply que ele retorna todas as mudanças que você tinha guardado, e sua aplicação está pronta pra receber visitas.

Update: eu não havia dito pois não tinha certeza, mas acabei de verificar que o git stash apply não simplesmente recupera o arquivo “stashado”, mas aplica somente as mudanças que você havia guardado, preservando o que mudar com o git pull. Nice!