Design Patterns

[Guilherme_90 33]

Hmmmm , resolver o problema é resolver, não tem importância pro usuário .. afinal, o usuário não vê o código fonte

Saber fazer uma escolha entre o certo e o errado, aí sim a história muda ..

 

 

 

Por que não ?

 

Por que cada um pensa de uma forma diferente.

[Henrique Barcelos 290]

Por que cada um pensa de uma forma diferente.

Sim, mas isso não quer dizer que não existam soluções piores nem melhores... E às vezes nem é uma questão de opinião, mas apenas de olhar para o código e ver que uma solução foi realmente melhor que a outra...

[Bruno Augusto 417]

Na verdade Henrique, eu penso ligeiramente diferente. Pelo menos em linguagens interpretadas, como PHP (não sei se todas as outras são), em alguns casos, vale a pena experimentar resolver ummesmo problema de formas diferentes visando maximizar a perfomrance.

 

Mas eu entendo o seu ponto de vista.

[João Batista Neto 448]

vale a pena experimentar resolver ummesmo problema de formas diferentes visando maximizar a perfomrance.

 

Sempre vale a pena, Bruno. O ponto é que, mesmo visando o aumento de performance, você deve sempre visar a manutenção.

 

Uma boa solução é aquela cujo custo de manutenção não seja alto por falhas na arquitetura. Construir software é fácil, manter software é difícil. Quando o software possui um custo recorrente de manutenção muito alto, então a solução tem algum problema e, certamente, precisará ser refatorada.

 

Quando você tem um software com uma grande performance e um baixo custo de manutenção, então você tem uma excelente solução.

 

;)

[visitante_php 0]

Eu sinceramente não sei onde, quem e porque raios alguém, algum dia, achou que misturar HTML com PHP não é uma boa prática.

 

 

oras a saida sempre sera html, pois sera sempre pelo navegador

 

 

Não importa se o PHP está embutido no HTML ou se é o contrário. O fato é que a mistura faz parte.

alguem ker usar php na linha de comando...so pode...

[João Batista Neto 448]

Ou eu não compreendi o seu comentário Igor, ou você não compreendeu o meu, mas veja só:

 

oras a saida sempre sera html, pois sera sempre pelo navegador

 

Não necessariamente, JSON e XML são formatos válidos e muito comuns em aplicações PHP.

 

alguem ker usar php na linha de comando...so pode...

 

Eu sequer consigo imaginar qual é o problema em usar em "linha de comando", você poderia dizer algum?

[Guilherme_90 33]

Sempre vale a pena, Bruno. O ponto é que, mesmo visando o aumento de performance, você deve sempre visar a manutenção.

 

Uma boa solução é aquela cujo custo de manutenção não seja alto por falhas na arquitetura. Construir software é fácil, manter software é difícil. Quando o software possui um custo recorrente de manutenção muito alto, então a solução tem algum problema e, certamente, precisará ser refatorada.

 

Quando você tem um software com uma grande performance e um baixo custo de manutenção, então você tem uma excelente solução.

 

;)

 

Disse tudo e mais um pouco.

[visitante_php 0]

Não necessariamente, JSON e XML são formatos válidos e muito comuns em aplicações PHP.

 

quando se trata de uma aplicacao especifica, você nao vai fazer um cliente comum, um usuario final ler xml ou json...

 

Eu sequer consigo imaginar qual é o problema em usar em "linha de comando", você poderia dizer algum?

 

eu tambem nao vejo problema, ate adoraria fazer isso, mas o povo esta implicando com php+html, nao viu? dizendo q php nao pode gerar ou se misturar com html...

[Henrique Barcelos 290]

eu tambem nao vejo problema, ate adoraria fazer isso, mas o povo esta implicando com php+html, nao viu? dizendo q php nao pode gerar ou se misturar com html...

 

Entenda o seguinte: HTML é estático. Sendo estático, ele pode ser facilmente cacheavel.

Vamos imagina o caso mais extremo, onde todo o HTML é gerado dando echo no PHP.

Todo usuário que acessar a página desencadeia uma sequencia de eventos.

1. O servidor detecta que estamos acessando uma página PHP
2. Depois ele localiza a página requerida e chama o interpretador PHP
3. O interpretador do PHP começa a ler o código, desde a primeira linha até o final.
4. Quando ele finalmente termina, começa a exibir a saída HTML

Quanto temos um arquivo HTML, ou mesmo um arquivo PHP onde o HTML está fora das tags <?php ?>, o interpretador não precisa ler essa parte do código, ou seja, já ganhamos performace aí.

Além disso, como já falei, o HTML é cacheável, ao passo que o PHP tem que ser lido toda vez.

 

Por isso que de certa forma, em termos de performance, é prejudicial utilizar um PHP gerador de HTML, mas em certos casos, é inevitável, ou até mesmo mais viável fazê-lo.

A chave é ter moderação no uso dos recursos que nos são disponibilizados.

[João Batista Neto 448]

Além disso, como já falei, o HTML é cacheável, ao passo que o PHP tem que ser lido toda vez.

 

Por isso que de certa forma, em termos de performance, é prejudicial utilizar um PHP gerador de HTML, mas em certos casos, é inevitável, ou até mesmo mais viável fazê-lo.

 

Quando fazemos a aplicação assumir a responsabilidade pela escrita da marcação, devemos assumir também a responsabilidade pelos mecanismos de cache.

 

Um bom sistema de cache, aliado a um bom motor de escrita da marcação traz como consequência uma grande versatilidade e uma velocidade inacreditável.

[Henrique Barcelos 290]

Concordo, João, mas quem desenvolve um sistema de cache quando passa a utilizar esse tipo de solução? :P

Acho que terá que concordar comigo que a criação de um bom sistema de cache não é nada trivial.

 

Na minha opinião, a imensa maioria dos comentários "8 ou 80" estão equivocados. "Não faça isso", "não utilize aquilo" não significa muita coisa sem um explicação bem clara.

"Não gere HTML com o PHP". Por que não?

 

Como tudo na vida, sempre existe o lado positivo e o lado negativo. Às vezes é só uma questão de opinião, às vezes são fatos irrefutáveis.

 

A verdade é que não existe solução definitiva, apesar de haver uma melhor, outra pior, sempre vai existir algum aspecto que possa ser melhorado, se não hoje, quem sabe com a adição de algum recurso à linguagem, por exemplo.

 

É muito bom ver umas dicussões tão alto nível por aqui :).

Há uns 3 ou 4 anos atrás, o fórum de PHP se resumia a problemas com sessões e inserção em banco de dados (:

[Bruno Augusto 417]

Olha, Henrique, não sei não, quando desenvolvi meu módulo de Cache, não foi assim tão difícil não.

 

Tá certo que eu só fiz dois "tipos" de Caching, por Arquivos e pela APC, mas ainda assim...

 

Acho que a maior dureza nesse quesito, seria utilizar o caching. A média dos programadores vão torcer os ossos para evitar algumas linhas a mais que eles potencialmente não entendem...