raelgc / template

PHP Template
http://raelcunha.com/template.php
GNU Lesser General Public License v2.1
73 stars 42 forks source link

Classe descontinuada? #21

Closed rafaelkapela closed 5 years ago

rafaelkapela commented 7 years ago

@raelgc Você pensa em continuar dando suporte a essa classe? Ou recomenda alguma outra classe de templates?

raelgc commented 7 years ago

@rafaelkapela Em termos de features, a classe continua funcionando como antes. O que poderia ser feito, é suporte ao composer, por ex.

O que você sugere?

npsouza commented 7 years ago

@rafaelkapela eu já usei esse repositório em vários projetos meus, um deles foi até grande, tive que fazer vários ajustes específico, inclusive, gostaria até de parabenizar o @raelgc pelo trabalho.

Mas eu queria "compartilhar" aqui um pouco da experiência que estou tendo com outros frameworks em relação a esse. O fato dessa classe ser bem simples é muito bom, me ajudou muito, porém, alguns projetos em que usei ela, quando precisei atualizar o projeto e escalar ele, encontrei dificuldades, mas ainda persisti porque gostei muito da solução. Com o tempo encontrei outras soluções que fazem isso de outra forma me permitindo escalar de uma maneira muito melhor.

Só queria chamar a atenção aqui, para analisar quando e como o seu projeto precisará escalar.

Pra se ter uma ideia, tenho utilizado o twig pra construir desde templates de email até sites institucionais, blogs e interfaces.

Espero estar ajudando.

raelgc commented 7 years ago

@nathanopereira, obrigado por compartilhar. Poderia descrever que tipo de dificuldade encontrou ao escalar?

Apenas para lembrar que essa classe aqui não é um framework, apenas uma classe para Templates.

Vi o twig, mas, numa primeira vista, é muito similar ao Smarty. Quais as vantagens dele sobre o Smarty?

rafaelkapela commented 7 years ago

@raelgc Eu uso a classe há mais ou menos 2 anos, também fiz algumas adaptações (como a remoção do erro quando o bloco não existe), coisas bem simples. Uso ela pra templates de email e de sistemas, o resultado anda sendo muito bom!

Seria legal, por exemplo, poder usar arrays ou objetos dentro do html, exemplo: $tpl->teste = array(1,2,3);

E no html: {teste[0]} ou {teste->show}

Algo assim, o que acha?

rafaelkapela commented 7 years ago

@nathanopereira Pois é, mas eu não queria partir pra uma framework. Alguns projetos, principalmente pequenos ou médios, essa classe funciona perfeitamente!

raelgc commented 7 years ago

@rafaelkapela O suporte a objetos já existe. A idéia de arrays é legal. Poderíamos adicionar isso e fazer o suporte a composer.

A parte de remover o erro de quando o blocos não existe, não sei se concordo... afinal os erros são Exceptions, basta fazer um try/catch se você não quer o erro.

Valkhan commented 7 years ago

O primeiro ponto é que eu acho que a classe hoje está bem sólida, com o @raelgc já disse, ela é uma biblioteca independente, e é fácil de colocar ela em qualquer projeto grande ou pequeno, e o fato de não misturar o HTML com PHP é um +1000 da classe, to cansado de ver framework grande colocando PHP pra gerenciar template, ao meu ver é erro grave de boas práticas.

@rafaelkapela não sei se é bem o que vc está sugerindo como suporte à arrays, pq se vc sabe qual posição do array vai usar... não vejo necessidade de usar um array,caso queira incluir um bloco por um array eu tenho um fork dessa classe que faz isso e tbm se passar um array de (chave -> valor) ele também adiciona.

@raelgc Em outra discussão similar, a respeito de tratamento de erro, o que fiz no meu fork é colocar como parâmetro se deve barrar na ocorrência de erros ou não, mantive erros como "arquivo não encontrado" sempre barrar pq, se a referência do arquivo ta errado o código todo provavelmente estará, é o caso de se pensar pq quanto mais "parâmetros" na classe mais dinâmica ela fica e mais projetos ela abrange.

+1 para o composer, é bem simples de fazer.

Outra coisa que vez ou outra (raramente) me vem na cabeça são uns "IFs" na classe, mas a única forma clara e objetiva que tenho de expor um possível comportamento é: Tenho 2 blocos que só devem ser renderizados quando X==Y, o que da pra fazer controlando os dois blocos individualmente então não me recordo de ter trazido á tona.

raelgc commented 7 years ago

Meu problema com remover as Exceptions de erros é o seguinte: em projetos onde a view (HTML) é complexa, fica muito difícil achar erros do tipo onde você digita errado o nome de um bloco ou variável e nada acontece.

O Smarty e outros HTMLTemplates (como os antigos da Pear) me trouxeram bastante dor de cabeça com isso: eles ignoram quando você atribui valor a uma variável ou bloco que não existe. Se você cometeu um erro de digitação, e está a horas cansado trabalhando no mesmo código, é difícil achar esse tipo de erro.

Por isso fez os erros como Exceptions, para permitir que ainda sejam ignorados.

Mas como é um projeto open source, e os usos são os mais variados, gosto da sugestão do @Valkhan, de colocarmos algumas variáveis de configuração pra isso.

Valkhan commented 7 years ago

@raelgc É exatamente esse o ponto, em primeira instância (durante o desenvolvimento), inicialize a classe com os erros ativados, na ausência de erros com nomes de variáveis, coloque para ignorar para não gerar erro para o usuário final.

Meus casos de uso 90% envolvem dados diretamente do banco de dados com um mínimo de tratamento, ou seja, há casos que mando 10 campos para serem adicionados dinamicamente alguns deles sendo de controle do banco de dados usados em outras áreas do código que não são pertinentes ao usuário final, e remover eles apenas para colocar no template necessitaria de tratamentos a mais e adições volumosas de linhas no código, usando a função customizada Template->addArray(), me resolve em 1 linha algo que por padrão teria que usar pelo menos 10-15 linhas.

Também dei uma curiada na proposta do Twig, é muito cedo para dizer pois não efetivamente testei ele, mas o que percebi é que tem diversas funções para tratamento de valores, se houver uma forma bacana de adicionar alguns "patterns" de formatação eu acredito que seria válido, evitaria muito tratamento prévio de dados e me economizaria ainda mais linhas de código por exemplo:

{DATA_INCLUSAO|date)} - Entrada: 2017-06-22 : Saída: 22/06/2017 {VALOR|moeda} - Entrada: 1234567.89 : Saída R$ 1.234.567,89 {VALOR2||R$0,00} - Entrada: "Não informado" : Saída: com dois pipes, assume um valor padrão informado seja ele fixo ou função quando a variável não for recebida (tipo um finally só que para variáveis)

Uma sugestão de implementação deste recurso é a definição de "helpers", funções na construção da classe que serão os "formatadores" de conteúdo, aí vale um estudo se haverá funções nativas de classe para tratamento de dados ou se será exclusivamente para funções fora da classe. (Talvez similar à função replace usada internamente na classe?)

De qualquer forma, se achar alguma dessas sugestões viáveis, podemos ir nos conversando após as 18hs para ver se conseguimos trabalhar em conjunto.

raelgc commented 7 years ago

Mas Paulo, isso já existe na classe, exatamente com essa sintaxe de 1 pipe. Você pode usar qualquer função que receba valor como primeiro parâmetro e retorne algo. Não existe essa variação com 2 pipes.

raelgc commented 7 years ago

Ou seja, da lista acima, o que não temos e seria legal implementarmos:

  1. Suporte a sintaxe de array
  2. Configuração dos erros (default como é hoje, opcional para ignorar)
  3. Composer
Valkhan commented 7 years ago

@raelgc Vish, to a tanto tempo usando a classe e nunca me atentei à esse recurso do pipe, vou fazer uns testes aqui. [EDIT: fiz o teste e estou indignado como não vi isso antes... vou ganhar algumas centenas de linhas de código agora].

Da lista, o item 2 vc pode dar uma olhada como fiz no meu fork, o 3 é bem fácil de fazer, é só vincular o repositório do github no packagist.

Valkhan commented 7 years ago

@raelgc Acredito estar com um tempo livre nestes próximos meses no período da noite, quer uma ajuda pra implementarmos essas 3 situações que ficaram em aberto?

Posso inclusive fazer um pull request com o item 2, e o composer não é difícil de fazer tbm.

raelgc commented 7 years ago

@Valkhan Seria ótimo contar com sua ajuda! :)

laudirbispo commented 6 years ago

A classe funciona muito bem! Mesmo em projetos grandes. A falta de um sistema próprio de cache é totalmente suprida por bibliotecas alheias. A ideia de não ter nenhuma linha de php no HTML é excepcional! Front-End devs só se preocupam com o que realmente lhes interessa.

raelgc commented 5 years ago

A única melhoria que ficou faltando das listadas acima é uma melhor sintaxe para array. Se alguém quiser continuar a discussão sobre isso, por favor, abra um novo issue.

Acredito que o issue original, perguntando se a classe foi descontinuada, foi respondido: claramente não está descontinuada.