Publicado em 9 de jul.

Parser de template "OneTime"

Um problema que todo programador PHP enfrenta é separar o HTML do PHP. Bom, muitos vão falar que não porque usam o Smarty, ou que não faz tanta diferença pois são eles mesmos que fazem o design. Mas quando você precisa criar um sistema do 0, e ele fica muito extenso, dificultando assim uma possível manutenção na template do site, o que você faz?

Eu e um amigo tivemos uma ideia, não sei se já existe. Queria compartilhar ela com vocês, para receber críticas e quem sabe construir aqui mesmo no fórum essa ideia.

Nos meus trabalhos onde eu não usava nenhum meio de separação do HTML para o PHP eu fazia assim:

menu.php

<?php
$conteudo = '<div class="menu">'.$menu["titulo"].'</div><div class="submenu">'.$menu["submenu"].'</div>';
?>

Possuía uma página para inserir as variáveis:

dados.php

<?php
include("menu.php");

$menu["titulo"] = "Titulo do menu";
$menu["submenu"] = "Titulo do submenu";
?>

 

E onde tinha que dar exibir os dados era só dar echo $conteudo.

É uma forma muito suja, muito ruim. Mas estive pensando. E se ao invés disso, fizesse um script que fizesse o parsing de um arquivo .html apenas uma vez? gerando um arquivo .php com uma variável com todo seu conteúdo?

Seria assim:

menu.html ou menu.php

<div class="menu">{#titulo#}</div>
<div class="submenu">{#submenu#}</div>

Existiria um arquivo com a classe parser, vamos supor que fosse parser.php.

E em outro arquivo a gente faria o parseamento.

<?php
include("parser.php");

$myparser = new parser();
$myparser->setFile("$conteudo", "menu.html", "$menu");

?>

Após isso ele geraria um arquivo menu.php:

<?php
$conteudo = <<<EOD

<div class="menu">{$menu["titulo"]}</div><div class="submenu">{$menu["submenu"]}</div>
EOD;
?>

É claro que este foi um exemplo MUITO simples da minha ideia, daria para elaborar muito mais. Daria até para fazer um sistema que atualiza as templates automaticamente, verificando a última vez que o arquivo foi alterado.

Mas o que vocês acham? Qual a opinião sobre o sistema? Críticas, acha que pode ter mais alguma coisa?

Obrigado.

Discussão (2)

Entre ou cadastre-se para participar da discussão

Entrar Criar conta

Bruno Augusto· 9 de jul.

Oras, mas é isso que a Smarty faz.

Claro que separar HTML do PHP é de vital importância, mas você acha realmente necessário colocar mais uma camada nesse bolo só para ter um HTML "bonitinho"?

Consideremos um MVC simples:

TestController.php

<?php

class TestController extends AbstractController {

 public function indexAction() {

 $this -> view -> data = array( 'name' => 'Bruno Augusto', 'age' => 23, 'phone' => '1234-5678' );

 $this -> view -> render();
 }
}

E a View:

<html>
 <head>
 <title>TestController View File</title>
 </head>

 <body>
 <!-- Controller Data -->
 </body>
</html>

Para exibir essas informações você pode fazer, no local demarcado:

<?php foreach( $this -> data as $column => $data ) : ?>

<dl>
 <dt><?php echo $column; ?></dt>
 <dd><?php echo $value; ?></dd>
</dl>
<?php endforeach; ?>

Ou pode fazer, a exemplo da Smarty. Já que a sintaxe mudou estarei usando um exemplo adaptado do próprio manual:

<dl>
 {foreach $data as $value}
 <dt>{$value@key}</dt>
 <dd>{$value}</dd>
 {/foreach}
</dl>

Nesse exemplo bem simples, até que coisa não ficou tão feia em nennhum dos casos. Mas operações levemente mais complexas, como arrays rigorosamente criados, com diversas dimensões, informações aliados à um HTML mal desenvolvido OU complexo demais vai com certeza deixar o primeiro código visivelmente mais poluído que no segundo.

Mas qual a diferença?

Veja, o primeiro código terá um fluxo de algo como:

REQUEST :seta: TestController

A requisição é feita e direcionada ao Controller adequado

TestController :seta: AbstractController :seta: View

O Controller instanciado, através de seu pai instancia a View, atribuindo à propriedade $view

TestController::indexAction()

O método é invocado, a variável de Template criada e o template exibido que, através do render() que pode ser um simples echo do arquivo.

Para o segundo código de View teremos uma continuação do esquema acima:

TestController::$view::render()

Ficou meio confuso mas significa o método render sendo chamado através da propriedade $view no contexto de TestController, ou de seu pai, como é o caso.

Esse render(), ao invés de um simpes echo teria algo como (desconsiderando autoload e devidas particularidades):

public function render( $file ) {

 require_once SMARTY_DIR . 'Smarty.class.php';

 $smarty = new Smarty;

 // Configura os paths da Smarty

 $smarty -> display( $file );
}

Por sua vez, em linhas gerais o Smarty::display() segue um fluxo de trabalho semelhante a:

Recebe o Arquivo :seta: Verifica se existe :seta: Se habilitado, busca e valida um cache

Lê o arquivo para uma string :seta: Instancia o Parser :seta: Analiza sintaticamente cada elemento {entre chaves}

Invoca as classes de função, modificador e/ou plugins, conforme o necessário

Cada uma dessas classes executa suas próprias rotinas de verificação e substituição

Devolve para a Smarty :seta: Passa ao compilador :seta: Gera o TPL :seta: Tenta gravar o arquivo

E só então exibe.

Viu toooooodo caminho que é percorrido ao sair do Controller? Agora imagina 10 mil usuários acessando seu site ao mesmo tempo :o

Claro, há o Cache para aliviar a barra. Porém nem tudo pode ser cacheado.

Agora pondere :thumbsup:

tesla· 10 de jul.

Então creio que não há um meio muito eficiente ainda de se separar os dois. No final vai acabar em um layout parecido com isso que você postou:

<?php foreach( $this -> data as $column => $data ) : ?>

<dl>
 <dt><?php echo $column; ?></dt>
 <dd><?php echo $value; ?></dd>
</dl>
<?php endforeach; ?>