È considerata una cattiva pratica avere PHP nel tuo JavaScript

54

Così tante volte su questo sito vedo persone che provano a fare cose del genere:

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

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

  });
</script>

Non penso che questa sia una sorta di schema in cui le persone cadono naturalmente. Ci deve essere una sorta di tutorial o materiale didattico là fuori che sta mostrando questo, altrimenti non lo vedremmo così tanto. Quello che sto chiedendo è che sto facendo un grosso affare o è una pratica veramente brutta?

EDIT: Stavo parlando ad un mio amico di questo che spesso mette il rubino nel suo JavaScript e ha sollevato questo punto.

È corretto posizionare dinamicamente costanti dell'applicazione nel tuo JavaScript in modo da non dover modificare due file. per esempio ...

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

è anche possibile codificare direttamente i dati che si intende utilizzare in una libreria

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

o dovremmo effettuare una chiamata AJAX ogni volta?

    
posta Greg Guida 22.12.2011 - 17:45
fonte

12 risposte

82

Tipicamente, è cattiva pratica usare il linguaggio X per generare codice nella lingua Y.

Prova a disaccoppiare le due lingue rendendo data la loro unica interfaccia - non mescolare il codice .

Nel tuo esempio, potresti migliorare il codice utilizzando PHP per popolare una struttura cfg disponibile per JavaScript:

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

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

In questo modo, PHP si preoccupa solo di popolare la struttura dei dati e JavaScript si preoccupa solo di consumare la struttura dei dati.

Questo disaccoppiamento apre anche il modo di caricare i dati in modo asincrono (JSON) in futuro.

Aggiornamento:

Per rispondere alle domande aggiuntive che hai chiesto con il tuo aggiornamento, sì, sarebbe buona norma applicare il principio DRY e lasciare che PHP e JavaScript condividessero lo stesso oggetto di configurazione:

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

  ...

Non c'è nulla di male nell'inserire la rappresentazione JSON della tua configurazione direttamente nella tua pagina come questa. Non devi necessariamente recuperarlo tramite XHR.

    
risposta data 22.12.2011 - 17:56
fonte
21

JavaScript generato dinamicamente è una pratica orribile e pessima.

Quello che dovresti fare è comprendere cosa significhi la separazione tra preoccupazioni e miglioramento progressivo.

Questo significa fondamentalmente che hai un codice HTML dinamico e JavaScript statico (che migliora l'HTML).

Nel tuo caso probabilmente vorrai un corso sul tuo div e selezionalo con un selettore di classe

    
risposta data 22.12.2011 - 18:04
fonte
10

Il problema più grande con il tuo snippet è che ti manca il # per renderlo un selettore jQuery valido;).

Direi che dovresti cercare di evitare di includere PHP nel tuo JavaScript, ove possibile. Cosa c'è di sbagliato nel cambiare il selettore nel tuo click() handler in una classe e aggiungere la classe all'elemento in questione se vuoi che il gestore venga licenziato, e non se non lo fai,

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

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

  });
</script> 

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

Ci sono circostanze in cui è necessario includere PHP nel tuo JavaScript; ma devo ammettere che sono pochi e lontani tra loro.

Un esempio è quando hai ambienti diversi; test, messa in scena e live. Ognuno di loro ha una posizione diversa delle risorse (principalmente immagini). Il modo più semplice per impostare il percorso in modo che possa essere utilizzato da JavaScript è qualcosa di simile;

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

Questa è una cattiva pratica secondo me, dato che avresti bisogno di chiamare questo file something.php e quindi non potresti comprimerlo per esempio, senza menzionare che non è corretto mescolare il tuo server con il tuo JavaScript . Cerca di limitare il più possibile il mix tra PHP e JS.

Puoi sempre farlo invece:

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

E quindi potresti chiamare questa funzione in un file php, per rendere queste missioni il più possibile ridotte.

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

Facendo questo (avendo file JS più grandi, non 2-3 linee dove non ha importanza) puoi trarre vantaggio dalla compressione del file JS e gli sviluppatori front-end si sentono a loro agio lavorando solo con JavaScript a mio avviso (come potresti scrivere Python, Ruby etc non solo PHP - e il codice potrebbe diventare sempre più grande a seconda di cosa devi fare lì.

    
risposta data 22.12.2011 - 17:50
fonte
6

Non penso che questa sia una cattiva pratica. Se l'ID richiesto nel tuo JavaScript è dinamico, non c'è altro modo per farlo.

    
risposta data 22.12.2011 - 17:47
fonte
6

Considererei questa cattiva pratica. Quando inserisci contenuti dinamici all'interno dei blocchi di script, devi sempre essere consapevole del fatto che l'escape in un contesto javascript non è così semplice come vorrai. Se i valori sono stati forniti dall'utente, è non sufficiente per fuggerli da html.

Il il cheat OWASP XSS ha più dettagli, ma in pratica dovresti adottare questo modello:

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

Quindi, in un file .js separato collegato dal tuo html principale, carica questo codice:

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

Il motivo dell'utilizzo di un file .js separato è duplice:

  • È memorizzabile nella cache, quindi le prestazioni sono migliori
  • Il parser HTML non viene attivato, quindi non vi è alcun rischio che un bug XSS passi attraverso qualcuno che inserisce un tag HTML <? php da qualche parte
risposta data 06.01.2014 - 10:33
fonte
5

Alcuni sostengono che è una cattiva pratica. Non perché è PHP in JS, ma perché è inline JS e quindi non verrà memorizzato nella cache dal browser per facilitare il caricamento la prossima volta.

IMO è sempre meglio usare JSON per passare variabili tra le 2 lingue, ma suppongo che dipenda da te.

    
risposta data 22.12.2011 - 17:53
fonte
5

Direi che in generale non farlo. Tuttavia se vuoi passare dati da PHP - > Javascript non mi farebbe impazzire per avere un blocco Javascript in linea dove hai il codice del modulo mostrato sotto. Qui il codice passa semplicemente i dati da php a javascript, non creando la logica al volo o simili. La buona parte di questa operazione rispetto a una chiamata Ajax è che i dati sono disponibili non appena la pagina viene caricata e non richiede un viaggio aggiuntivo sul server.

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

Ovviamente un'altra opzione è quella di creare un file di configurazione javascript da PHP tramite una qualche forma di script di compilazione che lo inserirà in un file .js.

    
risposta data 23.12.2011 - 13:47
fonte
4

L'unica cosa che riesco a pensare che possa davvero causare problemi è quando gli errori PHP sono impostati per essere visualizzati e quindi spinge un carico di HTML che mostra l'errore PHP nel tuo JavaScript.

Anche perché è nella sua sceneggiatura e quindi non mostra e a volte può essere necessario un po 'per capire perché il tuo script è rotto.

    
risposta data 22.12.2011 - 17:48
fonte
3

Dipende da chi, e se me lo chiedi, sì, lo considero di nuovo pratica per alcuni motivi. Prima di tutto, preferirei avere il codice javascript nel proprio file JS che il parser php non sarebbe in grado di toccare.

In secondo luogo, php viene eseguito solo al momento del server, quindi se si sta dipendendo da qualche variabile in php per cambiare il javascript, potrebbe non funzionare molto bene. Se c'è qualche impostazione di caricamento della pagina che vuoi controllare con javascript, in genere preferisco aggiungere quel valore al DOM con php in modo che javascript possa raggiungerlo quando e se vuole (in un div nascosto, per esempio).

Infine, solo per scopi organizzativi, questo può diventare molto fastidioso. È già abbastanza brutto mixare html e php (secondo me).

    
risposta data 22.12.2011 - 17:51
fonte
1

Il contenimento del PHP in un oggetto dati config è del 90%, ma la migliore pratica consiste nel separarlo completamente. Puoi usare un'API RESTful per richiedere solo i dati di cui hai bisogno, è un po 'più javascript ma con alcuni vantaggi.

  • Lo script è statico e può essere memorizzato nella cache in modo permanente
  • PHP non è più un vettore XSS
  • Completa separazione delle preoccupazioni

Svantaggi:

  • Richiede una richiesta HTTP aggiuntiva
  • javascript più complesso

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);
       }
    });
})
    
risposta data 06.01.2014 - 05:59
fonte
-3

Non è una cattiva pratica SOLO se è usata per l'inizializzazione del codice javascript, (nei miei temi WordPress, inizializzo i miei oggetti javascript con funzioni PHP come site_url () perché è l'unico modo per gestirli (forse potremmo usare un ajax richiesta di ottenere un json, e così ... ma è un rompicoglo.

Buona pratica:

nuovo javascriptObject ("");

Cattiva pratica:

/ * codice * / document.get_element_by_id (); / * codice * /     
risposta data 02.03.2013 - 23:41
fonte

Leggi altre domande sui tag