Tag Archive for php

Smarty Template Engine: Usar ou não?

Antes de responder a pergunta feita no título desse post primeiro precisamos entender o que é template engine, o que é Smarty e por que usar uma template engine?.

O que é Template Engine?

Template Engine (motor de template) é um processo, parte de um software ou um software, capaz de receber um ou mais documentos formatados, um ou mais modelos de dados, compilá-los e retornar um ou mais documentos de saída.
De forma bem simples, o template engine é a parte de um programa responsável por pegar um arquivo de modelo (template), que representa a saída do programa e preenchê-lo com dados da execução atual, retornando o documento final para o usuário.
Logo, tem-se que o código de processamento (Controller) está separado do código da visualização (View), podendo assim alcançar o padrão de arquitetura MVC.

O que é Smarty Template Engine?

Existem várias Template Engines para várias linguagens de programação. Inclusive, vários frameworks, como o Django (para Python) possuem sua própria engine.
PHP, como linguagem, não é diferente e possui um conjunto de aplicações do tipo Template Engine. Dentre essas aplicações existe o Smarty.
Smarty é a Template Engine mais popular para PHP, e me atrevo a dizer que Smarty é a template engine mais popular dentre todas as template engines de todas as linguagens.
Basta tentar uma busca no Google pelo termo template engine, e você verá logo após o artigo do Wikipedia quem aparece.
Também, o projeto Smarty existe desde 2002, o que dá uma certa credibilidade em relação as engines mais novas.

Utilizo o Smarty desde que o vi pela primeira vez, em 2006.
Desde então, não sei programar PHP sem utilizá-lo!
As vezes procuro novas templates engines para não ficar preso/bitolado no Smarty, mas para PHP nenhuma engine conseguiu chamar minha atenção.

Por que usar uma template engine?

O primeiro motivo é querer separar o código HTML (ou outra forma de saída do seu script) do seu código PHP é evitar o código spaghetti, que é quando tem-se aquela bagunça de, no mesmo arquivo (código-fonte) termos PHP-Html-JavaScript-CSS, tudo junto e misturado, o que é bem comum no mundo PHP (MAS NÃO DEVERIA SER COMUM!)

O segundo motivo é a manutenção.
Quando utilizamos uma template engine, separando o código-fonte (controller) do layout(view), podemos fazer várias alterações no layout final sem nem sequer precisar abrir o arquivo do código fonte.
Por exemplo, levem em consideração o WordPress. Ele separa o código da plataforma de blog do código do layout. Podemos então alterar várias vezes o layout do blog sem nem sequer abrir o código fonte da plataforma de blog.
Porém, o WordPress não usa uma template engine. O que ele faz é importar e executar arquivos PHP que definem o layout.

O terceiro motivo é trabalhar com designers.
Na facilidade (e problema) citado no exemplo do WordPress, o nosso caro designer teria que aprender a programar em PHP para conseguir fazer um layout.
Não é legal.
Sem querer ofender ninguém, mas designers não estudam para isso e podem não ter uma “mente lógica e algorítmica” que muitos programadores possuem. Claro que existem exceções, e temos por ai grandes designers-programadores.
Mas, quando trabalhamos em uma equipe de desenvolvimento, queremos manter cada membro focado na sua atividade. Ter que fazer o designer aprender PHP ou ter que migrar o layout de HTML para PHP pode representar perca de foco, tempo e dinheiro.
Para isso, as template engines implementam pequenas funções chaves (tags), como loops para preencher os options dentro de um campo select.
O designer não precisa aprender a programar. O que ele precisa é conhecer as tags da template engine, que são poucas, e conhecer o nome das variáveis que virão do código-fonte, que pode ser definido na documentação do projeto.

Smarty Template Engine: Usar ou não?

Agora podemos responder a pergunta feita no post desse artigo.

Se você acredita que seu projeto precisa atingir pelo menos 1 dos três pontos supra-citados e este será programado em PHP, você é um forte candidato a utilizar o Smarty.
Você pode optar por usar outra template engine, mas para finalizar este artigo, e responder a pergunta Smarty Template Engine: Usar ou não? gostaria de citar alguns pontos que me fizeram escolher esta ferramenta e que me fazem permanecer com ela por 6 anos consecutivos.

  • Eficiência – quem faz o trabalho é o PHP.
    Um das tarefas executadas pelo Smarty é traduzir o seu template para PHP. Logo, seu template é analisado pelo PARSER do PHP, o que torna a tarefa Smarty simples e rápida.
  • Sem RetrabalhosSmarty não possui overhead.
    Em sua primeira execução, o template é traduzido para PHP, análisado pelo parser do PHP e salvo. Nas futuras execuções, basta executar o arquivo PHP gerado em conjunto com os dados passados pela aplicação.
    Assim, não existe o retrabalho de sempre executar a operação de tradução e PARSER do template.
    Smarty percebe se seu template foi modificado e, então, o recompila.
  • Cache – Com cache, não há retrabalho.
    O template é compilado e salvo junto com os dados da execução para ser reutilizado sem precisar ser TRADUZIDO, PARSEADO, COMPILADO JUNTO COM OS DADOS.
    Basta apenas ser exibido para o usuário.
    Simples assim.
  • Herança de Templates – Uma forma simples e intuitiva de reutilizar códigos de template no seu projeto.
    Assim, escrevendo menos e produzindo mais!
    Herança de Templates é uma idéia nova, muito bem utilizada no Django.
  • E MUITO MAIS! – Parecendo um vendedor de itens pela tv, mas é verdade!
    Tags customizáveis, delimitadores, um conjunto de tags úteis que fazem muito em apenas uma linha, capacidade de plugins, facilidade de tornar um template internacionalizado (vários arquivos de lingua, um arquivo de template), etc

E ai, vai usar ou não?

[Comparando Frameworks PHP] Parte 01: Introdução

PHP e eu:

Programo com PHP a um pouco mais que 5 anos.
Como gosto de construir projetos sólidos que dependam muito pouco de códigos externos, sempre abominei a utilização de frameworks.
Nas minhas aplicações a única biblioteca que não era desenvolvida por mim e nem pela minha equipe era o Smarty Template Engine. Também pudera, depois que conheci o Smarty passei a achar ser impossível fazer um bom projeto sem utilizá-lo.
Na primeira empresa que trabalhei conheci o Propel, um ORM para PHP. Uma bela mão na roda, mas isso era 2006. Na época o PHP5 ainda era tido como novidade, e o danado do Propel as vezes apresentava uns bugs esquisitos e aleatórios, por isso parei de utilizá-lo.

Frameworks e Python:

Ultimamente tenho brincado bastante com Python e web.
Podem descordar de mim, mas acredito que hoje em dia é praticamente impossível achar um projeto Python para web que não utilize um framework.
Existem muitos frameworks para colocar seu código Python na web. Todos são muito robustos, cheios de bibliotecas e facilidades incorporadas, sem contar que grande parte ainda aceita plugins externos de forma fácil.
São tantos frameworks que eles são divididos em categorias como, por exemplo, os micro-frameworks, que fazem o básico que é ajudar a por o servidor no ar e antender as requisições GET e POST, ou os full-stack frameworks, que fazem de tudo. LITERALMENTE TUDO! ORM, Views, Url Dispatcher, Forms, Template engines etc.

Por que PHP e não Python:

Python é uma linguagem realmente legal e que faz com que o programador sinta prazer em programar.
Mas tenho uma maior fluência e experiência com o PHP e ainda prefiro trabalhar web com PHP. Pode ser que isso mude um dia, mas por enquanto, na minha opinião, programar para a web é sinônimo de PHP.
Também tem o fato de que ninguém ainda conseguiu me convencer que, no tocante desempenho, Python é melhor que PHP, quando falamos de aplicações WEB.
Por isso decidi que iria aprender um ou dois frameworks para PHP e que iria começar a usá-los daqui para frente. Quem sabe não encontro algo tão legal quanto Django?

PHP e os vários frameworks:

Foi ai que percebi que a comunidade PHP cresceu bastante nesses últimos anos, e que frameworks que eu ouvia falar que estavam em fase alpha hoje são os top-pica das galáxias.

Li vários artigos, conversei com alguns amigos e pesquisei bastante.
Existem boas opções mas existem poucas comparações.
Assim fica realmente difícil escolher um framework.
A solução é aprender e testar um por um e então adotar um ou dois para serem os meus “frameworks oficiais”.
Claro que não vou largar minha mania de programar sem frameworks. Mas, as vezes, pode ser que um projeto tenha um prazo muito curto, e frameworks ajudam bastante nessas horas.

A Experiência:

Para me ajudar a comparar os frameworks irei construir com cada um deles a mesma aplicação.
O pequeno projeto é um sistema de votação, onde os usuários podem criar uma nova enquete, com suas respectivas opções, votar e ver resultados.

É um projeto bem simples, que envolve CRUD no banco de dados, visualização, formulários, logins e permissionamento.

Julgando os frameworks:

Para poder decidir qual, ou quais, framework(s) vou utilizar, preciso definir como vou julgá-los.
As notas serão de 0 a 10 para cada quesito que for por mim analisado.
Por enquanto os quesitos que acredito que vou utilizar para a analise são:

  • Manuais, docs e tutoriais – Quanto mais fácil for para achar formas de aprender e tirar dúvidas, melhor
  • Facilidade de aprendizado, entendimento e uso
  • Liberdade de paradigma – As vezes você quer usar POO e as vezes não.
  • Templates – Quanto mais fácil de utilizar e legível for o template, melhor
  • MVC – O MVC é pré-requisito
  • Multiplos bancos e ORM – Pelo menos MySql e Postgre
  • Validação e segurança – O framework deve ajudar bastante!
  • logins, auths e sessions
  • DRYDon’t Repeat Yourself
  • Url Dispatcher – Url Routing
  • Licença de uso
  • Feeling – O quão bem me sinto programando com esse framework

Concorrentes:

Aproveitando o embalo de estar metendo a mão na massa para fazer análises de frameworks, analisarei também os dois principais projetos de PHP ORM, o Propel e o Doctrine.

  • PHP + Smarty – O basicão de cada dia, utilizando o PDO
  • PHP + Smarty + Propel – O basicão com a ajuda de um ORM, primeiro round
  • PHP + Smarty + Doctrine – O basicão com a ajuda de um ORM, segundo round
  • Framework CakePhp
  • Framework CodeIgniter
  • Framework Zend
  • Framework Yii
  • Framework Symfony
  • Framework Akelos
  • Framework Kohana
  • Framework DooPHP

Desenvolvimento:

Tenho muita vontade de brincar com cada uma desses modelos e frameworks, mas falta-me o tempo.
Codificarei o projeto supracitado em cada um dos modelos e frameworks, e publicarei um review para cada um deles aqui neste blog.
Também, quem quiser ver os códigos, eles estarão disponíveis no seguinte repositório:
https://github.com/frenetic/PHP-FrameWorks-Comparison

Transformando imagens em arte ASCII com PHP

Para mostrar que programar não é puramente escravidão, trouxe um pequeno código para deixar o dia mais divertido.
Venho hoje ensinar como transformar imagens em arte ASCII, utilizando a linguagem de programação PHP.

No nosso exemplo iremos pegar esta imagem:

E transformar em mais ou menos isso:

Para tanto iremos precisar da linguagem PHP (como diz o título do artigo, duh!) e da biblioteca GD ativada nas configurações da linguagem, o que é bastante comum nos servidores e instalações desktop (vide xampp).

O código que faz a conversão é o seguinte:

<?php

/*    abrimos a imagem    */
$arquivo = imagecreatefromjpeg("epic.jpg");

/*    verificamos se estamos com o stream aberto    */
if ( $arquivo ) {

    /*    pegamos a largura e a altura da imagem para ser utilizado no loop de leitura    */
    $largura = imagesx( $arquivo );
    $altura = imagesy( $arquivo );

    /*    damos um loop de linha em linha    */
    for ( $y = 0; $y < $altura; $y = $y + 1 ) {

        /*    damos o loop para ir de colona em coluna    */
        for( $x = 0; $x < $largura; $x = $x + 1 ) {

            /*    pegamos a cor alocada na posição (x, y) da iamgem    */
            $rgb = @imagecolorat($arquivo, $x, $y);
            $cores = imagecolorsforindex($arquivo, $rgb);

            /*    imprimimos um * com a cor do ponto    */
            echo "<font style='color:rgb("
                . $cores["red"] . ","
                . $cores["green"] . ","
                . $cores["blue"] . ")'>*</font>";

        }

        /*    chegamos ao fim do loop das colunas, então iremos imprimir a próxima linha    */
        echo "<br>";
    }
}
?>

Alguns podem não estar familiarizados com as funções:

  • ImageColorAt – Que le o ponto (x, y) da imagem e retorna um inteiro contento as cores R,G,B daquele pontoImageColorsForIndex – Que recebe o valor gerado por ImageColorAt e o divide em um array, o que facilita o nosso trabalho

Como podemos melhorar o nosso código?

Notem que o nosso loop lê a imagem ponto-a-ponto. Isso é legal pois deixa o nosso resultado bastante nítido, mas a ponto de desempenho é absolutamente pífio.
Podemos dar uma melhorada no desempenho da nossa conversão reduzindo a quantidade de pontos retirados da imagem, mas tentando evitar a perda de nitidez.

Ao invez de pegar ponto-a-ponto na imagem podemos pegar 1 ponto a cada 3 pontos fazendo a seguinte alteração:

alterar a linha 17 que contém:

for( $x = 0; $x < $largura; $x = $x + 1 ) {

para:

for( $x = 0; $x < $largura; $x = $x + 3 ) {

Note que o desempenho atual foi bem maior e que a sua imagem pode ter ficado um pouco distorcida.
Para melhorar o problema da distorção, faça a mesma alteração no loop das linhas, alterando a linha 14 que contém:

for ( $y = 0; $y < $altura; $y = $y + 1 ) {

para:

for ( $y = 0; $y < $altura; $y = $y + 3 ) {

Claro que este código pode ser melhorado mil vezes, tanto em desempenho quanto em funcionalidade.
Ele pode ser alterado para abranger outros formatos de imagem usando funções como ImageCreateFromGif, ImageCreateFromPng, etc.

 

Este artigo foi escrito no site PapoGeek e pode ser lido na URL:
http://www.papogeek.com.br/2010/07/transformando-imagens-em-arte-ascii-com-php