As estruturas PHP devem gerar JavaScript?

Eu notei que um PHP frameworks; Zend , Cake e Symfony ; Parecem gerar JavaScript ou permitir que ele seja incorporado como uma string no próprio PHP. isso é uma boa ideia? De pessoas que usaram essas estruturas / bibliotecas, qual a sua experiência trabalhando com os usuários do Ajax e JavaScript? Tem sido fácil de manter? Isso reduz o tempo de desenvolvimento?

Não, é uma má idéia,

O javascript gerado geralmente significa que o site nem funcionará sem ele (como muitos sites da asp.net). Se você quiser fazer coisas mais complexas ou quiser aumentar a acessibilidade, não há outra maneira de se aproximar do que separar o HTML de CSS e Javascript.

Seperating Javascript também torna o seu código mais sustentável, pois você não precisa fazer com que seus desenvolvedores frontend do lado do cliente se metam com seu código PHP e vice-versa.

A melhor maneira de usar o Javascript é permitir que o primeiro php gire seu html e, no final dessa página, inclua seus arquivos javascript e use a funcionalidade como onDomReady. Isso também não o obriga a usar uma biblioteca específica apenas porque sua estrutura está usando isso como base para o Javascript gerado.

Esta é uma questão bastante subjetiva, mas, pessoalmente, não gostaria que uma estrutura de back-end fizesse isso por mim. É melhor manter uma separação limpa entre a lógica do negócio, a apresentação e os comportamentos do UI do lado do cliente por vários motivos:

  • Aplicações mais sustentáveis.
  • Mais fácil de testar componentes individuais.
  • Colaboração mais fácil. Diferentes conjuntos de habilidades podem funcionar em diferentes áreas.
  • Deve ajudar a garantir que sua aplicação não confie no JavaScript no ambiente de usuários finais.

Pessoalmente, eu gosto de escrever o meu Javascript à mão, discretamente para que eu apenas tenha que adicionar um evento extra para document.domReady com, por exemplo, os parâmetros corretos. Essa pequena function de disparo, em seguida, leva a bola rolando.

Melhor prática do dia:

Mantenha o código do frontend e o código do backend desencadeados tanto quanto você pode

Eu diria que isso depende, como qualquer coisa. Certamente há algum valor em ter widgets “inteligentes” do lado do servidor. Por exemplo, um widget que “conhece” como se atualizar através de AJAX, ou um formulário que pode lidar com o lado do cliente e validação do lado do servidor. O último é um exemplo do qual seria caro e demorado e propenso a erros para rewrite o código de validação chato no cliente. Não requer javascript em foguete, de modo que, desde que sua estrutura possa lidar com isso discretamente, eu realmente recomendaria essa rota. Além disso, o código da estrutura que irá lidar com o material da GUI também (a ext ou algo parecido), também não é uma má idéia.

No entanto, qualquer coisa mais complicada do que isso, use o próprio Javascript.

Eu pessoalmente adoro escrever meu próprio Javascript, então eu realmente não quero que ele seja escrito para mim, mas eu não vejo isso como sendo particularmente “perigoso” ou “prejudicial” para ter estruturas que o façam por você, desde que seja devidamente feito. O meu maior problema com eles é que a maioria deles funcionará enquanto quiser o comportamento padrão de um recurso, mas, assim que você quiser algo um pouco diferente para atender às necessidades do seu projeto melhor, é preciso muito trabalho para personalizá-lo. foi melhor servido para fazê-lo você mesmo. Pelo menos essa foi a minha experiência com a automação javascript do CakePHP.

Minha experiência com os ajudantes do Javascript e do Ajax no CakePHP tem sido muito positiva.

Eles permitiram que os desenvolvedores do lado do servidor prototidiassem e criassem resources que, de outra forma, exigiria que alguém com experiência real do lado do cliente fizesse, tudo sem ter se preocupado com a qualidade do código javascript que eles “escrevem” e deixando os verdadeiros engenheiros front-end gratuitos para se concentrar nos resources avançados do lado do cliente.

Não é uma boa idéia para o PHP gerar Javascript. O único javascript que eu recomendaria exportar é atribuições simples do JSON como o seguinte:

 

Esta é a maneira mais fácil de desinfetar a informação do PHP e deixá-la acessível ao javascript no cliente. No entanto, qualquer outra coisa deve ser escrita em arquivos JAVASCRIPT reais que são referenciados com tags na cabeça do documento. A única aparência de Javascript dos arquivos do lado do servidor, que eu diria que está bem, é algo colocado no “onclick” e outros atributos desse tipo.

A justificativa para isso é que o Javascript deve ser escrito e mantido por pessoas de front-end que conheçam o Javascript e o site deve ser capaz de trabalhar (pelo menos parcialmente) sem javascript. Não há motivo para gerar Javascript em linha com espaguetes.

Confira minha estrutura do PHP, PHP On Pie ( http://phponpie.com ) para obter um exemplo de como implementar isso corretamente. Ele mantém o JS e o PHP separados, exceto quando exporta o JSON como mostrado acima. No entanto, ele também fornece convenções para facilitar a interoperabilidade entre o cliente eo servidor via AJAX.

Eu acredito que você deve manter os idiomas separados. Mesmo que eles possam se complementar. Dessa forma, você pode escolher a implementação do referido idioma e criar uma mistura que seja perfeita para você.

Eu acho que há definitivamente um lugar para o javascript gerado. (1)

A razão número um para o javascript gerado é a facilidade de manutenção. Todas as dependencies são explicitamente codificadas e configuradas a partir da estrutura (PHP, ruby, scala, python). Por exemplo, se você mover seus ativos ou alterar o diretório de upload, basta atualizar a configuração e assistir as coisas Just Work.

Precisa de validação de input no lado do cliente para tirar alguma carga do seu servidor? (2) Deixe a estrutura gerar código de validação correto derivado diretamente do seu modelo de dados para você. Com a população gerada e javascripted, sua estrutura pode servir formulários HTML estáticos pré-renderizados a partir do cache. Esta pode ser uma grande vitória se os seus formulários contêm muitas opções e opções.

1) Supondo que o cliente tenha decidido que está certo para o site depender (mais ou menos) do javascript, com todas as advertências que isso implica. A degradação graciosa pode ou não ser possível ou desejável.

2) Você também precisa da validação do lado do lado do servidor, mas você sabia disso, certo?