PDO e controllo dei campi da inviare

[Virus_101]

Non so dissuadendo sto solo dicendo di fare attenzione usando le variabili nelle stringhe ... e quinid prima partire dal colmare le lacune sulla gestione delle var, quindi passare a PDO, che non e' semplice e richiede cmq delle buone e solide conoscenze di base.

Dal canto mio odio concatenera le varibile come ho psotato sopra.
Preferisco sempre sempre sempre "stringa testuale testo vario".$array["campo"] ;
Evito anche le chiamate del tipo $mioArray[campo] esplicito sempre $mioArray["campo"] o con apici singoli in base a cosa devo fare..... Tutto qui nessun attacco , nessuna politica di dissuasione verso PDO .... ect.... solo uno spunto per eseguire dei test che facciano capire la differenze tra apici singoli e doppi , cose che crea spesso confusione

[torrone]

e ringrazio entrambi per le dritte

[k.b]

Originariamente inviato da Virus_101
Non so dissuadendo sto solo dicendo di fare attenzione usando le variabili nelle stringhe ... e quinid prima partire dal colmare le lacune sulla gestione delle var, quindi passare a PDO, che non e' semplice e richiede cmq delle buone e solide conoscenze di base.

Dal canto mio odio concatenera le varibile come ho psotato sopra.
Preferisco sempre sempre sempre "stringa testuale testo vario".$array["campo"] ;
Evito anche le chiamate del tipo $mioArray[campo] esplicito sempre $mioArray["campo"] o con apici singoli in base a cosa devo fare..... Tutto qui nessun attacco , nessuna politica di dissuasione verso PDO .... ect.... solo uno spunto per eseguire dei test che facciano capire la differenze tra apici singoli e doppi , cose che crea spesso confusione

Io invece sono assolutamente contrario alla concatenazione di stringhe, che peraltro da queste parti va tanto di moda. E' una cosa che crea solo confusione, continue virgolette aperte e chiuse, punti, tanto che la maggior parte delle volte le domande che contengono stringhe del genere hanno errori di sintassi.

L'interpolazione delle variabili direttamente nelle stringhe e' una funzione molto utile, se il linguaggio lo permette non vedo perche' non approfittarne. Trovo molto piu' leggibile questo:

$message = "Sono presenti {$data['quantity']} {$data['item']} al prezzo di {$data['price']}."; 

di questo

$message = "Sono presenti ".$data['quantity']." ".$data['item']." al prezzo di ".$data['price']."."; 

[Virus_101]

Capisco ma ognuno si trova comodo a modo suo, a meno che lo standard definito per un progetto non dica altrimenti.

capisco la comodita' di innestare le variabili direttamente nelle stringhe ... ma io prefereisco di no. E sinceramente le virgolette non mi fanno confusione grazie anche a come viene eseguito l'highlight del codice.

inoltre quando devi fare cose come generare stringhe html usare apici singoli e' meglio degli apici doppi altrimenti devi costantemente eseguire l'escaping di tutti i carattere " per gli attributi etc...


$html = '<div id="'.$variabile.'">'.$contenutoDiv.'</div>';
piuttosto di
$html = "<div id=\"$vairabile\">$contenuto</div>" ;

alla fine non cambia nulla, e' a discrezione di chi scrive il codice come le modalità di identazione. L'importante e' sapere bene cosa si sta usando e come funziona. Tutto la. Poi PDO .

Meglio chiedere questo ot cmq.

[k.b]

Infatti non devi mai generare stringhe HTML, l'HTML si scrive fuori dal PHP.

(comunque anche nel tuo esempio preferisco DI MOLTO la seconda versione, onestamente non comprendo come qualcuno possa trovare piu' leggibile la prima, gia' solo affiancare un apice a una virgoletta - cioe' tre trattini simili attaccati - e' follia pura)

[Virus_101]

Ripeto ognuno di noi scrive come vuole. E non serve scatenare lacuna guerra di religione a riguardo, come gli annosi dilemmi vi-vim-emacs etc......

Si html viene generato da php .... altrimenti che senso ha usare php ? ......
Per quanto riguarda le view che fai tutto in js/ajax ?
QUando devi tabellizzare dei dati come li fai ?
Quando devi generare vouchers ?
Quando devi impostare la pagina in base a determinati parametri che fai ?????

Usi la soluzione ibrida ?

<div id="<?=$id?>"><?=$contenuto?></div>

..... pensa se hai delle tabelle con molte colonne e una procedura che deve stamparle....
Io sincermanente preferisco creare la stringa completa html in relativa procedura php e quindi innestare il blocco dati nella pagina. COsi' se devo cambiare posizione alla tabella o ai div etc.... sposto 1 var ... invece di tutto il for o altra funzione chiamata direttamente nel cosidice html (cosa che odio fare)

[k.b]

Non ho capito bene le tue domande. Le view sono appunto view, fondamentalmente codice HTML che comprende variabili e costrutti PHP. In questo modo i dati e la loro visualizzazione sono completamente indipendenti.

Va bene le preferenze personali sulle piccole cose, ma quello che stai dicendo tu e' l'anti pattern per eccellenza dello sviluppo web. Il concetto di templating e separazione codice/markup sono assolutamente fondamentali.

Per dire, se devi creare una lista di libri scrivi una cosa del genere?

$lista = "<ul>";
while ( $row = mysql_fetch_array($result) ) {
    $lista .= '[*]Autore: <span class="author">'.$row['autore'].'</span> - Titolo: <span class="title">'.$row['titolo'].'</span>[*]';
}
$lista .= "[/list]"; 

[Virus_101]

SCusa e come lo fai senno ?

while($condizione)
{
?>
[*]<?=$dato[$indice]?>

<?
}
?>

WP fa cosi' e ti pare una cosa giusta ?

?????????
avrai delle procedure che "producono" i dati impaginati e tale produzione sono stringhe che vai ad innestare dove ti servono ....
Sinceramente sono io che non capisco come pretendi di generare il codice html ove devi tabellizzare dati o generare menu... se non hai procedure che generano l'ooprtuno codice a partire dai parametri di controllo .....

[k.b]

Originariamente inviato da Virus_101
SCusa e come lo fai senno ?

while($condizione)
{
?>
[*]<?=$dato[$indice]?>

<?
}
?>

WP fa cosi' e ti pare una cosa giusta ?

?????????
avrai delle procedure che "producono" i dati impaginati e tale produzione sono stringhe che vai ad innestare dove ti servono ....
Sinceramente sono io che non capisco come pretendi di generare il codice html ove devi tabellizzare dati o generare menu... se non hai procedure che generano l'ooprtuno codice a partire dai parametri di controllo .....

E' molto semplice, ed e' quello che ogni sistema ragionevolmente organizzato fa: PRIMA preparo i dati in apposite strutture, POI li inserisco in un template.

Ad esempio, prima il codice che elabora i dati, li estrae dal database, ci fa quello che deve fare e li mette in un array con un formato prestabilito

$data = array();
// esecuzione query
// estrazione risultati
// eventuali elaborazioni necessarie, tipo formattazione date o valute
// registrazione di tutto nella struttura $data 

view o template di visualizzazione

<ul>
<?php foreach ( $data as $item ): ?>
[*]
        Autore: <span class="author"><?php echo $item['author']; ?></span> - 
        Titolo: <span class="title"><?php echo $item['title']; ?></span> - 
        Prezzo: <?php echo $item['formatted_price']; ?>
    
    
<?php endforeach; ?>[/list]

Qual e' il vantaggio di questo approccio? Che se un giorno invece che estrarre i dati da una query li dovrai prendere da un webservice, dovrai solo cambiare il codice che crea $data e non dovrai nemmeno toccare il template che funzionera' perfettamente (fintanto che rispetterai il formato di $data). Allo stesso modo se un giorno vorrai stampare i dati in una tabella, piuttosto che restituirli come stringa JSON o chissa' che altro, dovrai solo cambiare il template senza minimamente modificare il codice che estrae ed elabora i dati.

In piu' puoi separare lo sviluppo del codice da quello dell'interfaccia (volendo anche assegnando le due parti a due persone diverse in un team), puoi avvalerti degli strumenti che un editor ti offre per la scrittura di HTML (cosa che dentro una stringa PHP non sempre e' possibile) e in genere tieni la tua applicazione piu' ordinata e modulare.

Quello che fa wordpress e' esattamente quello che dici tu, infatti wordpress e' un anti pattern terrificante. Se ti vai a vedere le varie funzioni tipo wp_nav_menu() sono codice PHP che contiene stringhe HTML generate tramite concatenazione ed echo. Una roba oggettivamente ingestibile.

[Virus_101]

<ul>
<?php foreach ( $data as $item ): ?>
[*]
        Autore: <span class="author"><?php echo $item['author']; ?></span> - 
        Titolo: <span class="title"><?php echo $item['title']; ?></span> - 
        Prezzo: <?php echo $item['formatted_price']; ?>
    
    
<?php endforeach; ?>[/list]

MA scherzi !!!!! Questo che hai postato e' proprio quello che fa quella schifezza di wp !!!!!

Sono pienamente d'accordo sul fatto di tenere assolutamente separata gestione dei dati dalla loro visualiuzzazione e in ogni mio script prima preparo i dati e poi li visualizzo.

Ma fare come dici te nel'estratto di codice sopra NO !
EW' proprio la cose che odio mescolare a sto livello php e html non mi piace. Io preferisco incapsulare tutto in funzioni o metodi statici (dpende dal contesto in cui lavoro) per cui ogni elemento che diventerà parte della pagina sia gestito dalla relativa procedure e quindi , si a questo punto come dici te se devo cambiare qualcosa cambio 1 cosa e sono tranquo.

Poi ogni situazione ha le sue prerogative e necessita e avolte come da te postato puo' risultare una cosa comoda, ma di sicuro NON nella gestione di architetture con templates et affini dove un design pulito e i giusti metodi possono fare davvero la differenza tra un'accozzaglia di codice html misto php ad una pagina ben strutturata e ben leggibile nonche' facilmente manuntenibile.

inoltre quanto da te postato e' assolutamente non-riutilizzabile a meno di fare copia incolla, e se devi riusare la stessa struttura in una pagina differente o in un wdget esterno che fai ? copia-incolla ? e se poi devi modificare la struttura ? La cerchi in ogni pagina e la fai ri-copia-incolla...... No sinceramente avere una classe del tipo

class decoratedElement()
{
public function toHTML()
{}
}


che poi ti estendi come ti pare nel codice ti da la possibilita di gestire le strutture come sopra moooooooooolto piu' elegantemente .

Ossia

1- leggi i dati
2- cicili id ati estratti da db e li converti in elementi decorati(crei un set di elementi decorati)
3- hai i dati in una struttura che oira puoi stampare con il metodo toHtml() che ritorna rigorosamente una stringa non mettere echo al dentro !!!!!!
Questa struttura la pouoi usare dove ti pare. E se vuoi gestire i template, beh chi si fa il suo template basta che si gestisce la
classe myTemplateDecoratedElement extends decoratedElement

Oppure applicando il pattern decorator


interface basicDecoratedElement
{}

class stdDecoratedElement implements basicDecoratedElementù
{}

// E poi tutte le estensioni che ti pare !!!
class superFicusDecoratedElement extends stdDecoratedElement
{}


Queste classi lavorano proprio come dicevo io forgiano le stringhe html a partire dai dati a disposizione e le rendono disponibili per il massimo (e il giovanni ) della riusabilità ed estensibilità. e come vedi non ci sono porzioni di codice

<ul><? foreach($data as $d) ?>
[*]$d

<? end foreach ?> [/list]

ma avremo una cosa ben differente
$ficusElements = new superFicusDecoratedElement($data) ;
$ficusElementsHTML = $ficusElements->toHtml();

e quindi nel codice html basta iniettare la var con tutto il codice fatto, questo oggetto e' riutilizzabile in qualsiasi widget vuoi fare o qualsiasi altra porzione del tuo template...
il codice e' piu' agile e meno legato. Sinceramente e' proprio quanto hi proposto nel codice che spezza tutta la parte del pattern sopprattutto del decorator... (mcv e' un'altra storia).
E cmq proprio come posti e' lo stesso cha wp appunto nelle sue procedure di stampa dei menu etc.... il core code prone delle classi che echoano il codice propio il quel modo ....
Sinceramente io resto dell'idea che tale metodo sia una approccio che a lungo andare si ritorce contro... e crea piu' proiblemi di quant ne risolva sul momento.

Se vuoi stampare dati in un template e fare un gestore di template... c'e' di meglio che

<? if() ?>
codice html
<? end if ?>

A volte si e' costretti.... e si devono calare le brache e fare cosi' ma se si puo' evitare a monte con una buona progettazione .... e' sempre meglio farlo