Muito se fala em usar ou não Templates. Afinal, que maravilha seria separar o código PHP do HTML, não é mesmo? Quando me deparei com essa dúvida, fui atrás de fóruns de várias comunidades PHP. A sonora maioria dizia:

"Use Templates... é a uma grande opção para entender melhor o código."

"É a melhor forma de separar o trabalho do programador do trabalho de designer"

E até exageros como:

"Não sei como eu programava antes sem usar templates"(!)

Depois que li isso tudo, pensei ser o único estúpido da face da Terra que não programa utilizando templates. E pra achar o melhor template, novamente a sonora maioria dizia que o Smarty era a melhor opção, tanto em performance, quanto em legibilidade e simplicidade do código.

Após dois dias estudando o Smarty, não vi melhora em nada. Contudo, como a sonora maioria dizia que era a melhor opção, resolvi me aprofundar um pouco mais. Quanto mais eu estudava, mais eu achava que estava certo. E mais eu queria estar errado. Eu nunca fui de nadar contra a corrente. Até que eu decidi gastar 1/3 do meu sofrido salário de bolsista de Iniciação Científica para comprar um livro de PHP avançado que explicava com detalhes o template Smarty.

"Agora sim, irei usar essa fabulosa técnica". Mas nem o vazio da minha conta bancária me convenceu.

Pela reação calorosa beneficiando o Smarty e outros templates, sei que nesse momento eu devo estar sendo tanto odiado quanto o Bush (epa, quem começou a brincadeira dos exageros não fui eu!). Mas está na hora de explicar o por que do meu não agrado com templates.

Antes disso, recomendaria que vocês lessem o livro "Better, Faster, Lighter Java". Apesar de ser voltado pra linguagem Java, a idéia que o autor passa serve para qualquer linguagem. Em poucas palavras, ele retrata um ente que eu já refletia há certo tempo: "O de programar para dar sustentação à própria programação". E isso em Java tem aos montes!

Para exemplificar melhor, há uma história engraçada que ele relata no livro que é mais ou menos assim (não sei a história decorada):

"O autor certo dia foi trabalhar voluntariamente no México, na criação de casas populares. No começo do dia, ele tinha que misturar todo o cimento manualmente. Isso o deixava muito cansado pelo resto do dia. Até que ele chegou para o gerente de obras e perguntou por que não compravam um misturador de cimento automático. Eis a resposta do gerente:

‘Boa idéia, mas quem irá mexer nessa máquina? Ela é complexa, e precisa de tempo para ser aprendida.

Outra coisa, quem irá carregá-la de um lugar a outro? Não temos caminhonetes aqui, apenas vans. E essas máquinas são muito pesadas. Precisa de várias pessoas para carregá-las de uma cidade a outra. É impraticável.

Mais um ponto, aonde iremos armazená-la? Ela é muito grande, e precisaríamos criar um depósito para tal.’
Até que o autor se convenceu que a obra não tinha estrutura para suportar tal máquina".

Pois bem, mas o que eu pretendia exemplificar era o porque de não concordar com o uso de templates. Vou explicar minha visão explicando de uma forma diferente: mostrando as qualidades do Smarty e argumentando em cima delas.

1) "De forma resumida, o objetivo dos modelos é separar a lógica de programação da lógica de exibição... Para o designer, é mais fácil entender lidar com os elementos de um sistema de templates do que um código de programação PHP."

Abaixo anexo um exemplo de código ".tpl" tirado de um livro:


Você acha que o designer terá menos trabalho com esses códigos do Smarty embutidos? Não seria muito mais fácil nós programadores criarmos códigos PHP bem elaborados para o designer colocar simplesmente um include e a função desejada?

Realmente, isso é separar o código PHP do HTML, mas separou o HTML do código do Smarty? Sinceramente, acho que é trocar seis por meia dúzia.

2) "O código PHP torna-se mais simples e legível"

Exemplo de código PHP para trabalhar com o Smarty:


Mais simples e legível? Pode-se criar páginas HTML com um padrão de codificação muito bem escrito. O PEAR possui um. Houve até um artigo que falava sobre isso aqui no phpbrasil. E essas outras especificações do Smarty? Tudo bem, é simples, mas leva um tempo para se aprender. E não são todas as pessoas que tem conhecimento sobre o Smarty. Ou seja, um outro programador PHP pode olhar esse código e levar um tempo para entender. Então, seria mais simples fazer um código PHP bem documentado, coeso, de acordo com o PEAR, por exemplo. Ou não?

3) "Portanto, você tem duas opções: ter um código confuso e atingir o máximo de desempenho em suas aplicações ou melhorar a compreensão e manutenção do seu código, apesar de perder um pouco de desempenho."

Apesar do sistema de cache que o Smarty possui, não podemos negar que a perda de performance é notável. Aliás, o autor esqueceu que podemos ter uma terceira opção: Ter o máximo de desempenho e o código legível. Pois bem, podemos fazer isso sim.

Estou montando uma arquitetura para projetos onde trabalho. Mas tem um princípio básico: o bom uso de includes. Podemos montar arquivos só com código PHP e darmos um simples include e chamar a função no HTML. Não mais do que isso. Essa opção foi descrita, corajosamente, por um dos leitores do phpbrasil. E foi rejeitada por muitos, claro.

Eu poderia escrever mais e mais e mais, sendo que seria era um livro, não um artigo.

NÃO estou dizendo que o Smarty ou qualquer outro tipo de template não deve ser usado de maneira alguma. Esse artigo reflete a minha opinião. Mais uma coisa: não sou uma pessoa radical. Você consegue me convencer facilmente. É só ter um bom argumento que mudo de idéia. Mas devo informar, que não achei nenhum bom argumento que pudesse me convencer sobre o uso de templates. Não até agora. Opiniões serão bem vindas.

Outra coisa são os escopos dos projetos. Cada projeto pode ter uma solução diferente. E isso é uma decisão de equipe. Onde trabalho, já construí sistema pequenos, médios e grandes. Nenhum deles, contudo, vi a necessidade de se usar templates.

Isto não quer dizer que não uso nada, além do puro PHP. Acho fantástico o uso de abstração para acesso a bando de dados. Não importa qual o banco, você acessa de forma simples e viável. Dois bons exemplos são a extensão dbx e as classes PEAR::DB e PEAR::MDB. Mas isso é conversa para outro artigo.

Bom, é isso. Já estou esperando as notas zeros para esse artigo. Sem problemas.

Abraços a todos, e por favor, não me odeiem.