Linux slogan
Visite também: BR-Linux.org · Dicas-L · SoftwareLivre.org · UnderLinux

Linux banner
Linux banner
Linux banner
Linux banner


» Screenshot
Linux: Netbook com Lubuntu 12.10 e tema Mac OS X.
Por kaizerw


Artigo

Phperl, minha gambiarra para usar Perl como se fosse PHP
Linux user
arnaldoestevao
22/01/2008
Admiro muito o PHP, mas só isso, porque eu prefiro construir minhas páginas usando CGI/Perl, então eu bolei uma técnica para poder programar em CGI/perl como se fosse PHP, ou seja, usando um construtor WYSIWYG (Dreamweaver,NVU, etc).
Por: Arnaldo Luiz Estevao
[ Hits: 18867 ]
Conceito: 9.2   8 voto(s)8 voto(s)8 voto(s)8 voto(s)8 voto(s) + quero dar nota ao artigo

Introduzindo

Phperl

Embora tenha grande admiração pelo PHP, sempre tive dificuldade em migrar meus aplicativos de CGI/Perl para PHP, não sei se por inabilidade minha, mas sempre tenho um consumo elevado de memória quando habilito PHP no meu apache e uma queda significativa na performance das aplicações escritas em PHP comparada a mesma aplicação em CGI/Perl, no entanto sempre me incomodou o fato de não poder utilizar construtores WYSIWYG como o DreamWeaver ou o Komposer para editar a arte das minhas páginas, trabalhei muito nos últimos dois anos com sistema de templates, e acredito que consegui chegar a uma técnica que tem sido tão produtiva que resolvi compartilhar com a comunidade.

O pulo do gato

Existem duas coisas que são o pulo do gato desta técnica.

1. O fato da maioria dos construtores WYSIWYG e dos navegadores ignorarem o conteúdo dentro de uma tag .

Evidente, pois o php é executado do lado do servidor e não do cliente.

2. O poder da função eval() do perl.

Esta função pode interpretar quase um programa inteiro escrito em perl e até agora a única incompatibilidade que vi são as declarações de cabeçalho, que não podem ser feitas em tempo de execução de um script perl. Fora isto você pode escrever um sistema com milhares de linhas de código, inclusive declaração de subs e uso de módulos do CPAN que ela irá executar tranquilamente.

    Próxima página >>




Páginas do artigo

Outros artigos deste autor

Leitura recomendada

Comentários
[1] Comentário enviado por hugoeustaquio em 22/01/2008 - 13:48h:

PATAQUEOPARÉU!!! Procure um sistema de templates para o perl, que você vai ter todas essas vantagens sem fazer tamanha gambiarra medonha!


[2] Comentário enviado por removido em 22/01/2008 - 13:52h:

HAUAHAUHAUAHUAHAUHAUAHHAUAHAUHAUAHUAHAUH

O pulo do gato foi ótimo!!!

Cara, perfeito seu artigo, tô rindo até agora!!!

Cada um que vemos na internet!!! Parabéns, excelênte artigo!

=)


[3] Comentário enviado por Ragen em 22/01/2008 - 16:07h:

Amigão, nem por acaso você procurou pra ver se isso já não existia algo desse tipo?

Existe um módulo para Apache chamado mod_perl que tem a mesma função do mod_php que está disponível na grande maioria das distros atuais ^^

Ao invés de criar um Frankenstein, você poderia ter documentado como se faz a instalação desse tal módulo, um programa teste ou coisa do tipo.

E só pra finalizar... É sério, devem existir pelo menos uma dúzia de engines de template pra Perl - reinventar a roda, você deve ter muito tempo sobrando!


[4] Comentário enviado por marcosmiras em 22/01/2008 - 16:42h:

hehe...
O gato tá mais pra canguru... rs. O que o Ragen falou é muito considerável, ao invés de "reelaborar a roda" o ideal seria verificar um engine de template disponível...


[5] Comentário enviado por leandro_hamid em 22/01/2008 - 20:17h:

"Pulo do gato"!?, que é isso cara!!!!


[6] Comentário enviado por arnaldoestevao em 24/01/2008 - 16:29h:

O problema não esta no fato de eu não saber que existem outras soluções alem do php e sim da maioria dos editores WYSIWYG não saberem disso, o próprio Kompozer por exemplo exibe todas as tags que voce tentar colocar como perl embebido usando o módulo Embperl, além disso eu não reinventei nada tudo que fiz foi construir uma técnica de programação utilizando os próprios recursos e o poder que a que a linguagem Perl oferece sem utilizar nenhum módulo adicional para isso, mas quem não gostou que faça do seu próprio jeito , afinal nós usamos software livre.



[7] Comentário enviado por hugoeustaquio em 24/01/2008 - 17:26h:

Calma colega, não estamos tentando denegrir sua imagem, somente colocando sugestões melhores. Com certeza usando um sistema de templates você não passará por esse problema, pois com template você separa a visualização do código, mantendo os html's limpos.


[8] Comentário enviado por arnaldoestevao em 24/01/2008 - 17:57h:

Blz Eustáquio, mas manter o código totalmente separado também não é solução, a soluçaõ mais próxima que eu encontrei foi o EmbPerl, mas veja quando voce usa as tags [+ +] o kompozer por exemplo não entende que deva ignorar o conteúdo dentro desta tag, veja um exemplo clássico voce precisa construir uma tabela com linhas de cores de fundo diferente, geralmente o Webdesigner não sabe nada de código se ele não estragar o código ja ajuda muito e o programador é igual ao windows 3.0 ou seja só encherga 16 cores , eu preciso integrar o serviço dos dois, no mercado eu so encontro desenhistas que produzem 90% de seus contúdos usando Dreamweaver, e programadores só em PHP quando encontro. vejamos o caso da tabela multicor






if ($i /2 = int ($i/2)) {
?>

}
else {
?>

}
}
?>
cabeçalho
Linha par
Linha impar





veja usando esta técnica o desenhista consegue um visual +- 90% ao layout do resultado do script ele pode definir o desenho da tabela, styles, etc usando o dreamweaver ou kompozer por exemplo, com a template separada isto não é possivel, alem disso é muito complicado dar manutenção em script e template separados a produtividade cai muito ,
o PHP é excelente mas ou é mais lerdo ou eu não soube configurá-lo corretamente porque a velocidade dos scripts abaixou e o consumo de memória do servidor aumentou muito além disso eu teria que abrir mão de quase 10 anos de programação em CGI/perl, quando o pessoal acenou com a continuação do projetor perl no Perl6 ja orientado a objeto, eu preferi continuar em perl mesmo e utilizar a técnica acima descrita, o Ò do Borogodó seria criar minha própria DTD para permitir os
editores WYSIWYG reconhecerem a tag talvez eu faça isso.


[9] Comentário enviado por hugoeustaquio em 24/01/2008 - 19:42h:

Normalmente os sistemas de template possuem uma sintaxe para estruturas de repetição (normalmente de forma parecida com o JSP), sem que isso polua o html, mantendo compatibilidade com os editores WYSIWYG. Não conheço os sistemas de template para perl, mas uso muito o django, e os templates dele abrem perfeitamente bem em todos os editores que já abri. Talvez esteja faltando algo assim no mercado que seja escrito em perl, mas talvez valha a pena você procurar testar os templates para perl. A sintaxe do Perl Template Toolkit usa as tags "[% %]", teste se elas entram em conflito com o Dreamweaver (dentro dos valores de parâmetro dos imputs, dentro das tabelas, etc...). Qualquer coisa poste o resultado aqui. Ah, a propósito, a produtividade sobe muito quando se usa sistema de template. Talvez você tenha essa sensação devido a curva de aprendizagem, que é um pouco íngreme, mas quando você domina as opções de marcação do sistema, a produtividade sobe muito, e a facilidade de manutenção também.


[10] Comentário enviado por arnaldoestevao em 25/01/2008 - 10:09h:

não, as tags [+ +] e [% %] não são compatíveis com o DreamWeaver e poluem o html .


[11] Comentário enviado por hugoeustaquio em 25/01/2008 - 11:13h:

Ahá! Achei a solução definitiva para você! O Perl Template Toolkit pode mudar de tag de configuração. Veja no endereço http://template-toolkit.org/docs/manual/Config.html#section_TAG_STYLE

Assim você pode usar qualquer tag que não entre em conflito com o DreamWeaver, pode até usar a tag , mais eu te aconselho a usar a tag mais comum (creio que seja a mais usada por linguagens de marcação de template) que é <% %> e deve funcionar no Dreamweaver perfeitamente!


[12] Comentário enviado por arnaldoestevao em 25/01/2008 - 12:53h:

O dreamweaver aceita as tags <% %> o kompozer não, ja a utlização de comentários que foi minha primeira opção da um xabú com o dreamweaver, é que ele usa -> ao invez de --> pra fechar comentários,
então quando voce usa uma expresão $recordset->getvalue(0,0) ele suja o código html. Além disto com esta técnica eu transfiro 99% do código pra dentro da template até agora a única coisa que o perl não aceitou foi anexar módulos externos em tempo de run time, no resto a função eval se comportou de forma identica ao próprio perl e eu tenho scripts rodando com mais de 100 linhas de código inclusive com declaração de subs, utilização de funções em módulos externos e declaração de váriaveis globais , e também quando ocorre um erro de run time durante o desenvolvimento, ao invez de receber a tela 500 do apache eu recebo a mensagem de erro que o script esta gerando , fica bem mais fácil depurar e tratar erros

outra vantagem para mim é poder usar

ao invéz de

eu acho o primeiro mais limpo


[13] Comentário enviado por hugoeustaquio em 25/01/2008 - 14:08h:

Não senhor! Não se coloca 99% dos códigos de controle para dentro do template, nunca!
Nunca se usa um código como "$recordset->getvalue(0,0)" num template, seu código tera que passar um valor que será usado no template. Os sistemas de template possuem estruturas de controle porque elas ajudam a construir a visualização, como no seu exemplo de cores (que não possui nada referente ao controle, somente visualização) mas que não devem ser utilizadas para o controle da aplicação. Você continuará a usar seus códigos (inclusive com declaração de subs e mais de 100 linhas de código) só que agora retirará dele tudo o que é referente a visualização, facilitando (e muito) a manutenção do seu sistema.

Para não visualizar a mensagem de erro genérica do apache, bastará colocar um parâmetro que liga a debugação, fazendo com que o mesmo exiba a saída de depuração do script, ao invés do referido erro. O parâmetro é o seguinte: ErrorLog /usr/local/apache/logs/error_log que deve ser colocado no httpd.conf do apache (algumas distros mudam o nome ou a localização desse arquivo, mas creio que a maioria das distros o colocam em /etc/httpd/httpd.conf ou /etc/apache/httpd.conf), assim voltará a ser tão fácil depurar seus script quanto era antes. Caso você utilize mod_perl, será mais fácil ainda, nem precisará ver os logs, ele tem uma diretiva de debugação, mas lembre-se de desligar esses mecanismos quando for configurar um servidor de produção. Quanto a última vantagem que você apontou, o código do template não seria o que você colocou, seria o seguinte:



sendo que o caractere "$" foi eliminado. Com todo o respeito, essa opção é evidentemente superior, só pelo fato de não conter caracteres que podem atrapalhar os editores. Quem se encarregará de setar o valor de "link" será o seu programa que faz uso do template. Por fim, teste todas as opções de mudança de tag do sistema de templates no komposer, com certeza alguma não causará conflito com ele. Provavelmente a sintaxe funcionará, teste o exemplo abaixo e por favor poste aqui se isso deu certo ou não:


...
...
......
.........
......
......
.........
......
cabeçalho
Linha par
Linha impar


Eu optei por utilizar os templates no comentário, que deve ser previamente configurada, conforme link que eu já postei.
Por favor, substitua os pontos por espaços, eu os coloquei para que o código ficasse identado. Usei a operação "%" que já calcula o resto da divisão inteira. Creio que qualquer raio de editor possa trabalhar com esse código, afinal de contas os comandos serão reconhecidos como comentários para ele. Dá pra retirar alguns "", mas colocando cada comando em um bloco do template eu achei que ficou mais didático.

notas adicionais:
* o desempenho do php é lento, mas um acelerador de cache resolve o problema
http://www.ducea.com/2006/10/30/php-accelerators/
* se o comportamento do Dreamweaver não puder ser alterado, você pode alterar a configuração do template da seguinte forma:

my $template = Template->new({
...START_TAG => quotemeta('
Contribuir com comentário


  
Para executar esta ação você precisa estar logado no site, caso contrário, tudo o que for digitado será perdido.
Responsável pelo site: Fábio Berbert de Paula - Conteúdo distribuído sob licença GNU FDL
Site hospedado por:

Viva o Linux

A maior comunidade Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda em Linux.