É minha gente, vivendo e aprendendo. Quando eu penso que o framework CakePHP já o seu máximo, vem a versão 1.3, que poderia tranquilamente vir com uma nota de rodapé assinada por Zagallo, dizendo: “AÍ SIM! FOMOS SURPREENDIDOS NOVAMENTE!“.
Para calar os fanáticos por Ruby e os engomadinhos do Symfony, que se gabavam de seus schemas (arquivo que define a estrutura do banco de dados para que a mesma seja replicada facilmente pelos desenvolvedores) e de seus fixtures (arquivos que definem os registros básicos que um banco de dados deve ter para fazer operar ou testar o sistema), a equipe de desenvolvimento caprichou na implementação dessa última versão para oferecer essas features de forma decente.
E nada melhor para celebrar do que um bom caso de uso para exemplificar o uso dessas features. Imaginemos o seguinte cenário:
Desenvolvedor A faz commit da primeira versão do código, com o admin do sistema funcionando e tal. Só que a aplicação precisa de um usuário cadastrado no banco de dados para que o admin seja acessível. Logo, o que fazer?
- Insere-se os registros diretamente no banco de dados
- Executa-se o comando: cake schema generate. Assim, será gerado um arquivo .php com toda a estrutura do seu banco de dados
- Executa-se o comando: cake bake fixture all. Assim, todos os registros inseridos nas tabelas estarão disponíveis num arquivo .php também!
Beleza! Desenvolvedor A faz o commit novamente e todos os desenvolvedores terão acesso à estrutura e aos registros básicos das tabelas sem precisar se preocupar em entrar no banco de dados. E o Desenvolvedor B, que chegou agora e precisa setar seu ambiente?
- Executa-se o comando: cake schema create. Assim, toda a estrutura será replicada no banco de dados do Desenvolvedor B.
- Executa-se o comando: cake fixtures. Assim, todos os registros iniciais básicos serão replicados no banco de dados do Desenvolvedor B também!
E que a galera do Ruby e do Symfony não leve a mal, mas cada vez mais eu me pergunto: Usar outro framework pra quê?!
Grande abraço e até o próximo post!