É considerado uma prática ruim ter PHP em seu JavaScript?

54

Muitas vezes, neste site, vejo pessoas tentando fazer coisas assim:

<script type="text/javascript">
  $(document).ready(function(){

     $('<?php echo $divID ?>').click(funtion(){
       alert('do something');
     });

  });
</script>

Eu não acho que isso seja algum tipo de padrão em que as pessoas caiam naturalmente. Deve haver algum tipo de tutorial ou material de aprendizado que mostre isso, senão não veríamos tanto. O que eu estou perguntando é, estou fazendo muito grande isso ou é uma prática muito ruim?

EDITAR: Estava falando com um amigo meu sobre isso, que muitas vezes coloca Ruby em seu JavaScript e ele trouxe este ponto.

Não há problema em colocar dinamicamente as constantes do aplicativo em seu JavaScript para que você não precise editar dois arquivos. por exemplo ...

MYAPP.constants = <php echo json_encode($constants) ?>;

também é correto codificar diretamente os dados que você planeja usar em uma biblioteca

ChartLibrary.datapoints = <php echo json_encode($chartData) ?>;   

ou devemos fazer uma chamada AJAX toda vez?

    
por Greg Guida 22.12.2011 / 17:45
fonte

12 respostas

82

Normalmente, é uma prática ruim para usar a linguagem X para gerar código na linguagem Y.

Tente separar os dois idiomas, tornando data sua única interface - não misture o código .

No seu exemplo, você poderia melhorar o código usando o PHP para preencher uma estrutura cfg disponível para JavaScript:

<script type="text/javascript">
  var cfg = {
    theId: "<?php echo $divID ?>",
    ...
  };

  $(document).ready(function(){
     $("#" + cfg.theId).click(funtion(){
       alert('do something');
     });
  });
</script>

Desta forma, o PHP só se preocupa em preencher a estrutura de dados e o JavaScript só se preocupa em consumir a estrutura de dados.

Esse desacoplamento também leva ao carregamento dos dados de forma assíncrona (JSON) no futuro.

Atualização:

Para responder às perguntas adicionais que você fez com sua atualização, sim, seria uma boa prática aplicar o princípio DRY e permitir que o PHP e o JavaScript compartilhem o mesmo objeto de configuração:

<script type="text/javascript">
  var cfg = <?php echo json_encode($cfg) ?>;

  ...

Não há mal nenhum em inserir a representação JSON de sua configuração diretamente em sua página como esta. Você não precisa necessariamente buscá-lo via XHR.

    
por 22.12.2011 / 17:56
fonte
21

JavaScript gerado dinamicamente é uma prática ruim e ruim.

O que você deve fazer é compreender o que significa Seperation of Concerns e Progressive Enhancement.

Isso basicamente significa que você tem HTML dinâmico e JavaScript estático (o que aprimora o HTML).

No seu caso, você provavelmente quer uma aula na sua div e selecione-a com um seletor de turma

    
por 22.12.2011 / 18:04
fonte
10

O maior problema com o seu snippet é que você está perdendo o # para torná-lo um seletor jQuery válido;).

Eu diria que você deve tentar evitar incluir PHP em seu JavaScript sempre que possível. O que há de errado em alterar o seletor no manipulador click() para uma classe e adicionar a classe ao elemento em questão se você quiser que o manipulador seja acionado e não se você não o fizer;

<script type="text/javascript">
  $(document).ready(function(){

     $('.foo').click(funtion(){
       alert('do something');
     });

  });
</script> 

<div id="bar" class="<?php echo ($someCond ? 'foo' : ''); ?>">Hello</div>

Existem circunstâncias em que você precisa incluir o PHP em seu JavaScript; mas devo admitir que são poucos e distantes entre si.

Uma vez que o exemplo é quando você tem ambientes diferentes; teste, encenação e ao vivo. Cada um deles tem uma localização diferente dos seus ativos (imagens, principalmente). A maneira mais fácil de definir o caminho para que ele possa ser usado pelo JavaScript é algo como:

var config = { assets: "<?php echo $yourConfig['asset_url']; ?>" };
    
por 22.12.2011 / 17:49
fonte
8

Esta é uma má prática na minha opinião, como você precisaria chamar esse arquivo de algo.php e então você não poderia compactá-lo por exemplo, sem mencionar que não é ok para misturar o seu material de servidor com o seu JavaScript . Tente limitar a mistura entre PHP e JS o máximo possível.

Você sempre pode fazer isso:

function setOnClick(divid) {
 $(divid).click(funtion(){
   alert('do something');
 });
}

E então você poderia chamar essa função em um arquivo php, para tornar essas coisas tão pequenas quanto possível.

$(function() {
  setOnClick('<?php echo $divId; ?>');
});

Ao fazer isso (ter arquivos JS maiores, não 2 a 3 linhas em que não importa), você pode aproveitar a compactação do arquivo JS e os desenvolvedores front-end se sentem muito confortáveis trabalhando apenas com JavaScript na minha opinião (como você poderia escrever Python, Ruby, etc, não apenas PHP - e o código poderia ficar maior e maior, dependendo do que você precisa fazer lá).

    
por 22.12.2011 / 17:50
fonte
6

Eu não acho que isso seja uma prática ruim. Se o ID exigido em seu JavaScript for dinâmico, não há outra maneira de fazer isso.

    
por 22.12.2011 / 17:47
fonte
6

Eu consideraria essa prática ruim. Ao colocar conteúdo dinâmico dentro de blocos de script você sempre deve estar ciente do fato de que escapar dentro de um contexto javascript não é tão simples quanto você esperaria. Se os valores forem fornecidos pelo usuário, não é suficiente para escape-los via HTML.

A folha de dicas do OWASP XSS tem mais detalhes, mas basicamente você deve adotar esse padrão:

<script id="init_data" type="application/json">
    <?php echo htmlspecialchars(json_encode($yourdata)); ?>
</script>

Em seguida, em um arquivo .js separado vinculado ao seu html principal, carregue este código:

var dataElement = document.getElementById('init_data');
var jsonText = dataElement.textContent || dataElement.innerText  // unescapes the content of the span
var initData = JSON.parse(jsonText);

O motivo para usar um arquivo .js separado é duplo:

  • É armazenável em cache, portanto, o desempenho é melhor
  • O analisador de HTML não é acionado, portanto, não há risco de um bug XSS passar por alguém colocando uma tag rápida do <? php em algum lugar
por 06.01.2014 / 10:33
fonte
5

Algumas pessoas argumentam que é uma prática ruim. Não porque é PHP dentro de JS, mas porque é in-line JS e, portanto, não será armazenado em cache pelo navegador para facilitar o carregamento da próxima vez.

IMO é sempre melhor usar o JSON para passar variáveis entre os dois idiomas, mas acho que depende de você.

    
por 22.12.2011 / 17:53
fonte
5

Eu diria que, em geral, não faça isso. No entanto, se você quiser passar dados do PHP - > Javascript não me parece tão louco para ter um bloco Javascript inline, onde você tem o código do formulário mostrado abaixo. Aqui o código é apenas passar dados de php para javascript, não criando lógica em tempo real ou algo parecido. A boa parte de fazer isso versus uma chamada ajax é que os dados estão disponíveis assim que a página é carregada e não requer uma viagem extra para o servidor.

<script>
window.config = <?php echo json_encode($config);?>;
</script>

Claro, uma outra opção é criar um arquivo de configuração javascript a partir do PHP, através de alguma forma de script de construção que irá colocar isso em um arquivo .js.

    
por 23.12.2011 / 13:47
fonte
4

A única coisa que posso pensar que pode realmente causar problemas é quando os erros do PHP são definidos para serem exibidos e por isso ele empurra uma carga de HTML mostrando o erro do PHP em seu JavaScript.

Também porque é um script que, por isso, não aparece e às vezes pode demorar um pouco para perceber por que seu script está quebrado.

    
por 22.12.2011 / 17:48
fonte
3

Depende de quem, e se você me perguntar, sim eu considero isso de volta por algumas razões. Primeiro de tudo, eu prefiro ter o código javascript em seu próprio arquivo JS que o analisador de php não seria capaz de tocar.

Em segundo lugar, o php é executado apenas na hora do servidor, portanto, se você estiver dependendo de alguma variável no php para alterar seu javascript, isso pode não funcionar muito bem. Se houver alguma configuração de carregamento de página que você deseja controlar com o javascript, normalmente prefiro adicionar esse valor ao DOM com php para que o javascript possa alcançá-lo quando e se quiser (em um div oculto, por exemplo). / p>

Finalmente, apenas para fins organizacionais, isso pode ficar muito chato. É ruim o suficiente para misturar html e php (na minha opinião).

    
por 22.12.2011 / 17:51
fonte
1

Contendo o PHP em um objeto config data vai 90% do caminho, mas a melhor prática é separá-lo completamente. Você pode usar uma API RESTful para solicitar apenas os dados de que precisa, é um pouco mais de javascript, mas com algumas vantagens.

  • O script é estático e pode ser armazenado permanentemente em cache
  • PHP não é mais um vetor XSS
  • Separação completa de preocupações

Desvantagens:

  • Requer uma solicitação HTTP extra
  • javascript mais complexo

Script

//pure javascript
$.on('domready',function({
    //load the data
    $.get({
       url:'/charts/3D1A2E', 
       success: function(data){
           //now use the chart data here
           ChartModule.init(data);
       }
    });
})
    
por 06.01.2014 / 05:59
fonte
-3

Não é uma má prática APENAS se for usada para inicialização de código javascript, (nos meus temas WordPress, inicializo meus objetos javascript com funções php como site_url () porque é a única maneira de lidar com isso (talvez possamos usar um ajax) pedido para obter um json, e assim ... mas é uma dor na bunda).

Boa prática:

new javascriptObject ("");

Má prática:

/ * algum código * / document.get_element_by_id (); / * algum código * /     
por 02.03.2013 / 23:41
fonte