62 DBMS – aspetti architetturali

Pubblicato il di

Nella lezione precedente, abbiamo effettuato la pagina di login e registrazione passando da un form. Considerando la struttura del codice, risulta un po’ confuso e comunque abbiamo diverse porzioni di codice che potrebbero essere riutilizzate, o con dei cambiamenti o manutenzione, dovremmo andare a modificare diverse pagine tipo la connessione al database, il login … Se queste parti dobbiamo riutilizzarle, si dovrebbero fare dei copi e incolla, e per ogni modifica dovremmo modificare diverse pagine con un enorme lavoro. La soluzione sta nell’incapsulare (wrapper) le parti di codice in funzioni personalizzate richiamabili nelle pagine a cui servono. Un altro vantaggio sta nel non essere legati ai nomi dei campi:

$email = $_POST['email'];

Il campo email potrebbe cambiare o chiamarsi differentemente.

Un altro esempio, i messaggi di errore potrebbero essere riscritti in altra lingua, basta memorizzarli in un file e richiamare quella variabile a seconda della lingua da utilizzare e un altro file per un altra lingua.

Creo quindi una cartella my_ini fuori dalla cartella pubblica, dove inserirò i miei file ini con le configurazioni restituite nella forma chiave valore. Dentro la cartella sposto il vecchio file ini e aggiungo un file messaggi_errore.ini che contiene:

[errori]
connessione_fallita = connessione al server fallita. Impossibile accedere.
db_non_trovato = non trovo il database ...

vado poi ad assegnare la path della cartella ad una variabile:

$cartella_ini = "../my_ini";

e richiamo i miei dati

//recupero credenziali da file ESTERNO alla cartella pubblica del sito
$accessData=parse_ini_file($cartella_ini . '/confagtest.ini');
$messaggi_errore = parse_ini_file($cartella_ini . 'messaggi_errore.ini');

Ancora meglio invece che legarsi ad un percorso per ogni sito, posso usufruire del percorso già impostato nella chiave DOCUMENT_ROOT presente nella variabile server $_SERVER, aggiungendo il percorso della mia cartella ini. In questo modo avrò un percorso sempre fornito da quel server.

$cartella_ini = $_SERVER['DOCUMENT_ROOT']."/fagtest/my_ini/";

analogamente creiamo una cartella contenente i file da includere che chiameremo my_include e creiamo il file setup.php

<?php
 session_start();
 $nl = "<br />";
 $cartella_ini = $_SERVER['DOCUMENT_ROOT']."/fagtest/my_ini/";
?>

a questo punto includiamo il setup.php nel file login_migliorata.php

 include($_SERVER['DOCUMENT_ROOT']."/fagtest/my_include/setup.php");

ho trasformato 3 righe di codice in 1 e l’inclusione sarà sempre disponibile.

Potrei includere anche  i dati di accesso nel setup, oppure ancora meglio, potrei fare un setup.php generico che va bene per tutti i siti ed un setup_con_DB.php da usare per quelli che usano il database, dove includiamo il setup standard + i dati di accesso

<?php
 include($_SERVER['DOCUMENT_ROOT']."/fagtest/my_include/setup.php");
 
 $accessData=parse_ini_file($cartella_ini . 'confagtest.ini');
?>

a questo punto possiamo inserire nel setup.php anche i messaggi di errore e nella pagina elogin_migliorata.php includere il file setup_con_DB.php

 <?php
 session_start();
 $nl = "<br />";
 $cartella_ini = $_SERVER['DOCUMENT_ROOT']."fagtest/my_ini";
 $messaggi_errore = parse_ini_file($cartella_ini . 'messaggi_errore.ini');
?>

e nella pagina elogin_migliorata.php includere il file setup_con_DB.php

 include($_SERVER['DOCUMENT_ROOT']."/fagtest/my_include/setup_con_DB.php");

ora non solo il nostro file elogin inizia a diventare più snello, ma ne abbiamo guadagnato anche in flessibilità.

Esiste anche una forma di include, include_once che permette di includere ogni volta che un include richiama un file che include a sua volta , di permettere solo una sola inclusione.

 include_once("");

Se include o include_once falliscono verrà generato un warning, ma il programma continuerà a funzionare. Se si preferisce che tale problema venga considerato un errore fatale, e quindi l’esecuzione del codice deve stopparsi, si potrà utilizzare require o require_once.