PHP: Errori, programmazione OO, Namespaces e Composer

Configurazione di PHP

· I parametri di funzionamento di PHP sono impostati in un file php.ini che contiene numerose direttive - Es. memoria massima utilizzabile dallo script, dimensione massima di un corpo HTTP accettata, file di log, ecc

• Tra queste, ci sono anche quelle per la visualizzazione più o meno dettagliata degli errori - Di solito in produzione si visualizza "meno"

· PHP consente di sovrascrivere alcune direttive impostate nel php.ini direttamente in uno script - Funzione ini_set() - Le modifiche saranno valide solo per quello script

Visualizzazione degli errori

· In generale, in testa allo script: ini set ('display_errors' , 1) ; ini set ( 'display_startup_errors' , 1) ; error reporting (COSA MOSTRARE) ;

· Cosa mostrare? Flag binari che identificano errori veri e propri, warning, variabili non dichiarate (notice) - E_ALL, E_ERROR, E_WARNING, E_PARSE, E NOTICE

· Nel nostro caso, per non mostrare le notice: error_reporting (E ALL & ~E NOTICE) ;

Classi ed oggetti

Classi

· Oltre allo stile procedurale il PHP consente al programmatore di usare il paradigma Object Oriented.

· Quest'ultimo è preferibile per progetti di medie/grandi dimensioni: - maggior chiarezza e correttezza del codice; - manutenzione agevole; - possibilità di applicare pattern di programmazione avanzati.

Classi - sintassi

class [extends ] { // proprietà _ _ // metodi (tra cui costruttori e distruttori) } Le proprietà ed i metodi possono essere public (default), protected e private. Nota: non si può "spezzare" la definizione di una classe con gli pseudo tag (a meno che non occorrano all'interno del corpo di un metodo).

Esempio (1)

· Modelliamo i libri: isbn=$i; $this->titolo=$t; $this->autore=$a; $this->editore=$e; $this->pagine=$p; } } $l=new libro('8845290050','Il Signore degli anelli','John R. R. Tolkien' , 'Bompiani ' , 1359) ; echo $l->titolo; echo '

',var_dump($l),'

'; ?> Esempio (2) · Aggiungiamo un metodo ed il distruttore: class libro { function visualizza () { return $this->autore. ". < em>" . $this->titolo. ". ". $this- >editore. ", pp. ". $this->pagine; } function destruct () { echo '

sto distruggendo il libro con ISBN ' . $this->isbn. '

' ; } } $l=new libro('8845290050','Il Signore degli anelli','John R. R. Tolkien' , 'Bompiani ' , 1359) ; // invocazione del metodo: echo $l->visualizza();

Namespaces, Composer

Sommario

• Namespaces
• Librerie esterne
• Composer - Gestione delle dipendenze per PHP

Namespaces/1

· Meccanismo simile ai namespaces di XML · Risolve il problema della collisione fra i nomi di funzioni / classi / costanti - Che si presenta soprattutto quando adottiamo librerie esterne - es. due librerie che definiscono una funzione o metodo con lo stesso nome · È possibile quindi definire uno spazio dei nomi proprio, in ogni file che appartiene ad un progetto che vogliamo rendere pubblico - Per codice privato non ce n'è bisogno, - Ma conviene conoscere la sintassi per usare librerie altrui

Namespaces/2

· Definizione (all'inizio di ogni file): -

Namespaces/3

· Utilizzo: - Le funzioni/classi definite nel file con namespace TWC saranno accessibili altrove (dopo sua inclusione) con: o TWC\funzione( ... ); - Ifunzione() si riferisce invece ad una funzione con stesso nome ma definita localmente o ITWCIfunzione() è TWC\funzione( ... );

Utilizzo di librerie esterne

· Sono installabili in vari modi · Quello tradizionale: scarico uno zip e lo metto nella directory - Nascono problemi però quando una libreria necessita di altre librerie, e per questioni di licenza/manutenibilità non può includerla · Alternative per PHP: - PEAR - Composer - (PECL)

PEAR

. PHP Extension and Application Repository - https://pear.php.net · Primo tentativo di fornire un sistema di installazione di codice PHP - A linea di comando, stile apt · Mantiene un repository globale di librerie/applicazioni PHP sfruttabili da tutti gli utenti del sistema - I pacchetti sono "validati" dai gestori (umani) di PEAR o Quindi c'è un controllo di qualità, ma anche un limite ai pacchetti distribuiti · Gestisce eventuali dipendenze · È in via di abbandono a favore di Composer

Composer

. Dependency Manager for PHP - https://getcomposer.org - Ci sono cose simili per altri sistemi (es. npm per Node, bundler per Ruby) · Composer agisce localmente, progetto per progetto - Installa tutte le librerie necessarie in una directory specifica dentro quella del progetto (tipicamente vendor), sulla base delle dipendenze · Sempre a linea di comando, multipiattaforma

Composer: principi

Nato per favorire lo sviluppo di un ecosistema di • librerie facilmente installabili - Riguardo le quali, lo sviluppatore non dovrebbe vedere troppi dettagli (accoppiamento debole anche qua) · Quindi in generale le librerie: - Non creano file se non richiesti; - Hanno al massimo stato locale; - Non emettono output, header, ecc - Non dipendono da risorse specifiche di un sistema operativo · Lo sviluppatore: - Stabilisce le dipendenze, - Installa tutto con un comando, - Include tutto con un comando

Composer packages

• https://packagist.org - Aggregatore di package installabili con Composer - (principale, ma si possono specificare anche altri repository) • che poi però installo a linea di comando localmente … - sulla base di un file di configurazione in cui … definisco le librerie da cui dipende il mio progetto · Un package è definito da un vendor, un progetto, una versione

Come si usa/1

· Creo la directory del mio progetto; - Es. prova · Creo un file JSON in cui si dichiarano le librerie da cui dipende il mio progetto - composer.json { "require": { "vendor/package": "versioni" } } - (ed eventuali altre informazioni, soprattutto se voglio distribuire il mio progetto)

Come si usa: versioni

· La sintassi per definire le versioni è molto dettagliata · Exact: 1.0.3 · Range: >=2.0 >=2.0 <4.0 >=2.0 <4.0 | 6.0 1.0-2.0 ... · Wildcard: 2.0 .* · Next significant version: ~1.3 (uguale a >=1.3 <2.0.0) ~1.3.1 (uguale a >=1.3.1 <1.4.0) ^1.3.1 (uguale a >=1.3.1 <2.0.0)

Come si usa/2

· Una volta dichiarate le dipendenze, · Installo tutto con composer install - O php composer.phar install · Verrà creato un file composer.lock che specifica esattamente quali librerie sono state concretamente installate (da che URI, ecc) - Quindi se distribuisco il progetto, senza .lock vengono installate le versioni più recenti delle librerie richieste, - con .lock vengono installate le versioni esatte che ho usato io - Se ho bisogno di aggiornare: composer update

Come si usa/3

· Nel mio codice basta includere: · require (vendor/autoload.php); · Che si occupa di includere tutto il necessario - Cioè ciò che ho dichiarato come dipendenza e che ho conseguentemente installato · Accedo poi alle classi definite nelle librerie tramite spazio dei nomi (vendor\packagel ... )

Come si usa/4

· Il meccanismo di composer è molto più complesso, quel che abbiamo visto di solito basta per usare le librerie • ... ma se voglio distribuire il mio progetto, allora aggiungo altre informazioni al composer.json, e il mio progetto diventa a sua volta un package - composer.json { "name" : "TecWebCloud/Esempio", "version" : "1.0.2" "require": { "vendor/package": "versioni" } } • Si indicheranno anche i repositories di riferimento - Es. github