CodeIgniter: il peso piuma dei framework PHP
CodeIgniter è considerato un web application framework destinato agli sviluppatori che preferiscono il fattore della velocità rispetto alla possibilità di avere una grande varietà di funzioni. Secondo la pagina web ufficiale del progetto, l’obiettivo principale del design del PHP framework open source è quello di garantire il massimo delle prestazioni e della flessibilità con una struttura che sia il più ridotta possibile.
Cos’è CodeIgniter?
CodeIgniter è un web framework scritto in linguaggio PHP che vanta di poter conferire efficienza e velocità allo sviluppo di applicazioni web grazie al design del software particolarmente compatto. L’ideatrice di CodeIgniter è l’azienda statunitense EllisLab, che nel febbraio del 2006 ne ha rilasciato la prima versione ufficiale. Il 9 luglio 2013 ha poi annunciato di non riuscire, da sola, a radunare le risorse sufficienti per poter effettuare uno sviluppo del software, così un anno dopo il progetto è stato acquisito dal British Columbia Institute of Technology (BCIT). Il codice sorgente del framework è disponibile con licenza MIT e può venire scaricato tramite il servizio online GitHub. Da ottobre 2016 viene offerta l’ultima versione di CodeIgniter 3.1.2, disponibile gratuitamente per il download sulla pagina web ufficiale del progetto.
Assetto e struttura del framework
Il design orientato alla performance di CodeIgniter viene esaltato dall’assetto slanciato del framework PHP. Questo, infatti, si orienta sul modello di architettura per software Model-View-Controller (MVC). Il principio che sta alla base di MVC è la rigida separazione tra codice di programmazione e presentazione, realizzato grazie a un assetto del software di tipo modulare e il trasferimento del codice PHP. Si differenziano tre componenti principali: il modello (Model), la vista (View) e il controllore (Controller).
- Il modello (Model) rappresenta la struttura dei dati di un’applicazione web sviluppata sulla base di CodeIgniter. A questo scopo vengono definite delle cosiddette classi di modello (“model classes”) nel codice sorgente. Grazie all’accesso a un database, queste contengono funzioni specifiche con le quali possono venire aperte, salvate o aggiornate le informazioni.
- La vista (View) è quell’aspetto di un’applicazione che viene presentato all’utente finale. Di norma si tratta di un documento HTML nel quale i contenuti vengono integrati tramite PHP in maniera dinamica. La vista è quindi una sorta di template. CodeIgniter offre inoltre la possibilità di definire le sezioni di pagine web (come l’header e il footer oppure pagine RSS) come vista. Di norma le applicazioni web usufruiscono di diverse viste che propongono i propri contenuti usufruendo del medesimo modello. In questo modo è possibile presentare le differenti features del programma con diversi tipi di visualizzazioni.
- Il controllore (Controller) funge da entità mediatrice tra modello, vista ed ogni altra risorsa che occorre per elaborare una richiesta HTTP oppure per creare un sito web dinamico. Questo componente accoglie le richieste in entrata, cerca la vista desiderata e inoltra i contenuti al modello, il quale li ha caricati a partire da un database.
Grazie alla seguente grafica è possibile vedere l’interazione che intercorre tra i componenti MVC:
La struttura MVC fa sì che il design del software sia flessibile, e che i singoli moduli del programma vengano scambiati, elaborati e riutilizzati senza grande difficoltà. Premesso che non vengano effettuati cambiamenti sulle interfacce, le modifiche effettuate su un componente, invece, solitamente non hanno alcun effetto sul codice sorgente di altri componenti. La netta separazione tra logica del programma e visualizzazione permette che il codice di programmazione sia chiaro e ben strutturato. Le applicazioni web su base MVC sono considerate facili da usare anche durante la manutenzione. In caso di errore, il più delle volte la causa della sorgente di errore va ricercata tra uno di questi componenti.
Oltre a ciò, il modello di architettura MVC offre la possibilità di sviluppare separatamente la logica e il layout dell’applicazione web. Se gli sviluppatori back end e quelli front end lavorano parallelamente, le applicazioni verranno ultimate decisamente più in fretta. CodeIgniter usufruisce di MVC, ma non vincola del tutto gli utenti a usare questo modello di architettura. Mentre, per quanto riguarda i componenti controller e vista, si tratta di elementi obbligatori, i collegamenti al database tramite il modello sono invece opzionali. In più è anche possibile realizzare un’applicazione sulla base di CodeIgniter che abbia un’architettura del tipo HMVC (Hierarchical MVC Architecture), la quale amplia il modello MVC aggiungendo un livello di logica gerarchica.
Il flusso di applicazione del PHP framework
CodeIgniter si basa su un concetto di URL: ciò significa che il controller diventa l’unità centrale di monitoraggio tra vista e modello tramite l’inserimento di un URL nella barra di ricerca del browser. A questo scopo gli sviluppatori creano le cosiddette classi controller (classes). In questo caso si tratta di file PHP, che contengono diverse funzioni per caricare librerie (libraries), estensioni (plugins) oppure classi aiutanti (helper), per realizzare collegamenti alle banche dati, per integrare un modello oppure per ricercare una vista specifica.
Il flusso di applicazione di CodeIgniter si basa quindi sul seguente schema URL di base:
example.com/class/function/parameter
Al dominio (example.com) segue una classe controller che va coinvolta, come anche una specifica funzione controller. La conclusione è costituita da parametri (Parameter) opzionali: questi servono a trasmettere ID o variabili al controller scelto.
Nella pratica un URL di CodeIgniter potrebbe apparire come segue:
example.com/news/article/511
Un URL del genere richiama il controller news presente sul dominio example.com e lo induce a mettere in atto la funzione article (ad esempio per caricare una vista omonima per la visualizzazione dell’articolo). Quali sono i contenuti che devono essere richiamati tramite il modello a partire dal database, sono i parametri opzionali a deciderlo, i quali vengono trasmessi al controller assieme all’URL; in questo esempio un articolo con l’ID 511.
Nella configurazione finale il PHP framework rappresenta l’index.php in ogni URL dell’applicazione:
example.com/index.php/news/article/511
Questo file PHP contiene informazioni riguardo alla posizione dei file core del framework e a dove si trovano le librerie, estensioni, oppure classi aiutanti integrate, e in quale percorso sono i file di applicazione. L’elemento index.php serve quindi all’inizializzazione di tutte le risorse di base.
Se CodeIgniter opera su un server Apache HTTP, index.php può venire rimosso tramite mod_rewrite dagli URL delle applicazioni, per mettere a disposizione degli indirizzi web “puliti” agli utenti finali e ai crawler dei motori di ricerca. Gli sviluppatori inseriscono il seguente blocco di codice nel file .htaccess del server web:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]La struttura di base del framework PHP si regge innanzitutto sulle classi controller, sulle classi modello e sui template di vista.
Classi controller
CodeIgniter dà agli sviluppatori l’opportunità di programmare controller individuali come classi definite dall’utente. A questo scopo gli sviluppatori web mettono a disposizione un file PHP separato per ogni controller all’interno del percorso application/controllers/. I controller contengono la logica di programma di un’applicazione web sviluppata con CodeIgniter e vengono create sotto forma di sottoclassi dell’elemento CI_Controller class. All’interno del codice sorgente i programmatori fanno lo stesso grazie alla parola chiave extends.
class News extends CI_Controller {
}Essendo una sottoclasse, News eredita dalla classe genitore CI_Controller tutte le funzioni riguardanti la visibilità public e protected.
Nel PHP le parole chiave public, protected o private servono a definire la visibilità di una caratteristica o di una funzione. Se un elemento riceve la dichiarazione di public, tutte le classi di un software avranno accesso a questo elemento. Se, però, l’accesso deve essere limitato alle classi genitore e alle classi derivate, i programmatori adoperano la parola chiave protected. Un elemento che viene dichiarato private sarà esclusivamente a disposizione della classe definita dall’elemento.
Ogni classe controller definita dall’utente deve inoltre contenere una funzione di costruttore, tramite la quale si riescono a integrare librerie, modelli, banche dati oppure classi aiutanti. A partire dalla versione PHP5 viene utilizzato l’elemento __construct() come funzione di costruttore standard.
<?php
class News extends CI_Controller {
public function __construct() { //definisce il costruttore
parent::__construct(); //richiama il costruttore della classe superiore
$this->load->helper('url'); //carica una classe aiutante per le operazioni con gli URL
$this->load->helper('file'); //carica una classe aiutante per le operazioni con i file
$this->load->database(); //carica un database
$this->load->model('News_model'); //carica un modello con il nome di “News_model”
}
?>L’esempio mostra la classe News come sottoclasse di CI_Controller. La funzione di costruttore __construct() unisce due classi aiutanti, un database e il modello News_model. Le singole stringhe di codice vengono commentate poi all’interno del codice sorgente.
Tutte le classi di controller che vengono definite in PHP per CodeIgniter devono iniziare con una lettera maiuscola (News invece di news). Nell’URL, invece, si scrivono in minuscolo.
Funzioni controller
Se c’è la struttura di base del controller definito dall’utente, allora la logica del programma apparirà sotto forma di funzioni del controller, grazie alle quali è possibile richiamare le viste oppure realizzare interazioni con un modello integrato.
Affinché il controller sia in grado di caricare una vista, il documento HTML che sta alla sua base va inserito nel percorso application/views/ sotto forma di file PHP. Una vista semplice per la visualizzazione di un articolo potrebbe, ad esempio, apparire nel modo seguente:
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf-8">
<title><?php echo $title; ?></title>
</head>
<body >
<h1><?php echo $headline ?></h1>
<p><?php echo $content_body ?></p>
</body>
</html>I documenti HTML che contengono codice PHP devono essere salvati come file PHP (.php). Solo in questo modo è possibile stabilire che l’interprete PHP del server web rappresenta anche gli script e non emette il codice PHP solamente sotto forma di testo.
Per caricare una vista nel controller, si necessita di una funzione definita dall’utente. Nell’esempio di codice seguente entra in gioco la funzione article() per caricare la vista article.php.
public function article() {
if (!file_exists(application/views/article.php)) {
show_404();
}
$this->load->view('article');
}Il codice del programma va letto come segue: innanzitutto CodeIgniter verifica se il percorso application/views/ contiene un file con il nome article.php. Questa richiesta viene realizzata tramite il costrutto linguistico if e la condizione negata (!) file exists().
Se la condizione combacia e non c’è un file omonimo all’interno del percorso corrispondente, allora if propone il valore TRUE, e CodeIgniter applica la funzione show_404() avviata sotto il comando if. In questo caso l’utente riceverebbe l’indicazione che il file richiesto non esiste. Se, invece, la condizione if non viene soddisfatta e !file_exists viene valutato come FALSE, CodeIgniter applica la funzione $this->load->view('article'), la quale serve a caricare il file corrispondente come vista all’interno dell’applicazione.
Finché si tratta del formato PHP, il file desiderato può essere avviato nella funzione view() senza suffisso. Se, però, vanno caricati altri formati allora è obbligatorio apporre il relativo suffisso del file di ognuno.
Di norma CodeIgniter entra in azione nel contesto di applicazioni web dinamiche, preferite dagli utenti rispetto alle pagine HTML statiche. Ciò si può realizzare riempendo la vista di dati corrispondenti ai parametri che CodeIgniter riceve assieme all’URL.
example.com/news/article/511
Finora tramite la funzione $this->load->view('article') si caricava la visualizzazione per la rappresentazione dell’articolo. Ora, invece, vanno integrati specialmente i contenuti che sono collegati al parametro 511: si tratta di un ID che con l’aiuto di un sistema di management del database è collegato a un articolo di news specifico. Per leggere l’ID dal database e per caricarlo successivamente sul programma, è necessario completare l’esempio qui sopra perché venga richiamato il modello integrato all’interno del costruttore.
public function article($id) {
if (!file_exists(application/views/article.php)) {
show_404();
}
$data = $this->News_model->get_data($id);
$this->load->view('article', $data);}L’argomento di funzione trasferito, che nell’esempio appare con il nome di variabile $id, corrisponde alla parte dell’ID dell’URL, come ad esempio 511. La funzione del modello ancora da scrivere get_data() serve a caricare il contenuto dell’articolo collegato all’ID dal database. Il metodo view()- richiama la vista article e le trasmette questi dati sotto forma di un array associativo ($data). Il modello News_model trasmette quindi i dati selezionati al controller News, il quale li inoltra, a sua volta, alla vista. Tutte le operazioni connesse alla richiesta di dati vengono archiviati nel modello integrato.
Classi modello
I modelli vengono attivati in CodeIgniter per rendere disponibili funzioni con le quali è possibile effettuare delle specifiche operazioni relative al database. Proprio come le classi controller, anche le classi modello possono venire programmate con il framework PHP in modo che vengano definite dall’utente.
Per attivare una classe modello, innanzitutto viene assegnato un nome alla classe: in questo caso News_model. In maniera analoga alle classi controller, tutte le classi modello definite dall’utente sono sottoclassi della classe genitore CI_Model. L’ereditarietà si realizza tramite la parola chiave extends. Anche le classi modello connettono i database e altre risorse attraverso la funzione costruttore.
class News_model extends CI_Model {
public function __construct() {
parent::__construct();
$this->load->database();
}
}Sulla base di questa struttura seguono le cosiddette funzioni modello nelle quali gli sviluppatori definiscono tutte le operazioni del database che sono a disposizione del controller tramite il relativo modello.
Funzioni modello
Le classi modello permettono agli sviluppatori di definire funzioni individuali per le operazioni del database. In un esempio precedente abbiamo utilizzato la funzione utente get_data() nella classe controller News per estrapolare i contenuti dell’articolo dal database e caricarli nella vista. Nel modello definiamo solamente quali operazioni del database si nascondono dietro a questa funzione.
class News_model extends CI_Model {
public function __construct() {
parent::__construct();
$this->load->database();
}
public function get_data($id) {
$this->db->select('content');
$this->db->from('example_table');
$this->db->where('id', $id);
$query = $this->db->get();
return $query->result();
}Nella classe modello News_model la funzione sopra utilizzata get_data() viene definita come operazione database, che richiede alla colonna dichiarata sotto select() la trasmissione del codice ID ($id) a partire dalla tabella del database dichiarata sotto from() tramite get() e che, con l’aiuto della funzione result(),la restituisce sotto forma di array. Solitamente un modello rende disponibile una molteplicità di funzioni. Gli sviluppatori possono quindi attingere alla classe Query Builder, la quale comprende una serie di funzioni predefinite per le classiche operazioni database. Relativamente a questo argomento, potete trovare una panoramica nella documentazione ufficiale del framework CodeIgniter.
Gestione del routing con CodeIgniter
Quali sono le classi e le funzioni controller che devono essere coinvolte, viene prestabilito da CodeIgniter con un URL. Il framework web adopera la struttura URL classe/funzione/parametro. Questo schema di base si riesce ad adattare a piacimento: a questo scopo, infatti, CodeIgniter mette a disposizione il file routes.php nel percorso application/config/. Questo contiene un array con il nome di $route, che permette agli sviluppatori di definire propri criteri di routing.
Durante la configurazione finale si trovano tre inserimenti di default nell’array $route: il controller standard, una regola di routing per l’override 404 come anche una regola per la sostituzione automatica dei trattini (-) con i trattini bassi (o underscore) (_).
$route['default_controller'] = 'home/welcome';
$route['404_override'] = 'home/welcome';
$route['translate_uri_dashes'] = FALSE;La prima voce di default stabilisce il controller standard dell’applicazione. Questo viene caricato da CodeIgniter ogni volta che un URL non contiene ulteriori informazioni di routing al di fuori del dominio. Nell’esempio utilizzato la regola di routing definisce la classe controller home come controller standard. I visitatori che non danno alcun riferimento alla pagina web di destinazione all’interno dell’URL, verranno reindirizzati su home e visualizzeranno la vista welcome. È una consuetudine inoltrare alla homepage. Se non è stato definito nessun controller come standard, allora, una volta che si richiama la pagina iniziale, CodeIgniter mostrerà al suo posto la pagina di errore 404.
La seconda voce di default all’interno dell’array $route definisce un controller che viene richiamato ogni volta che il controller coinvolto tramite l’URL non è stato trovato nei file dell’applicazione. La regola di routing $route['404_override'] = 'home' sovrascrive la pagina di errore 404, che normalmente viene attivata in un caso del genere e, invece, conduce alla classe controller home.
La terza voce di default all’interno dell’array $route impedisce errori di routing grazie ai trattini di unione. Il trattino, infatti, non è un simbolo valido per il nome della classe o della funzione e viene quindi sostituito automaticamente negli URL già nell’impostazione standard.
Se va realizzata una regola di routing definita dall’utente per un URL dinamico, allora gli sviluppatori web hanno a disposizione due possibilità su CodeIgniter: gli inserimenti di routing per URL dinamici possono venire definiti con l’aiuto di wildcard (metacaratteri o anche caratteri jolly) o in alternativa con espressioni regolari.
L’elemento routes.php supporta due tipologie di metacaratteri:
I siti web con una grande quantità di pagine di errore 404 sono difficili da scansionare per i crawler, rendendo quindi faticoso l’accesso a contenuti rilevanti per i motori di ricerca. Ciò, oltre a provocare un effetto negativo sulla user experience, può avere un’influenza negativa sul ranking del motore di ricerca. Di norma gli sviluppatori web si impegnano a evitare pagine di errore 404.
| Wildcard di routes.php | Descrizione |
|---|---|
| :num | Funge da metacarattere solo per i caratteri numerici |
| :any | Funge da metacarattere per qualsiasi carattere |
L’esempio seguente mostra un inserimento all’interno del routes.php, che permette di rimuovere la funzione (article) dall’URL:
$route['news/article/(:num)'] = 'news/$1';Tramite il carattere jolly :num il parametro viene assegnato a un URL dinamico e salvato nella variabile $1. Finché le regole di routing vengono definite con :num o :any, allora vanno messe tra parentesi all’interno di routes.php.
L’elemento routes.php accetta inoltre regole di routing sotto forma di espressioni regolari. Entrambe le tipologie di metacarattere possono essere annotate come segue:
:num corrisponde a \d+
:any corrisponde a [^/]+Un’alternativa all’esempio qui sopra potrebbe dunque essere la seguente scrittura:
$route['news/article/(\d+ )'] = 'news/$1';Anche le espressioni regolari vengono messe tra parentesi all’interno di routes.php.
Una panoramica del flusso di applicazione
Il grafico seguente riassume in sette passaggi l’application flow di un’applicazione sulla base di CodeIgniter:
1. L’index.php serve a CodeIgniter come front controller per richieste HTTP in entrata. Qui vengono inizializzate tutte le risorse di base che servono per utilizzare l’applicazione.
2. A livello di routing, CodeIgniter verifica quale azione deve essere messa in atto. A questo scopo l’applicazione allinea l’URL nella richiesta con le regole di routing definite nel routes.php.
3. Successivamente al routing avviene il caching. Se si trova una risposta adatta alla request all’interno della cache dell’applicazione, allora questa verrà inoltrata direttamente al browser che ha inviato la richiesta. Altrimenti il controller esaminato durante il routing viene attivato con la funzione filtro preinserita.
4. Il framework CodeIgniter contiene un filtro integrato che intercetta richieste dannose. Ogni request HTTP subisce un controllo di sicurezza prima che l’applicazione carichi un controller adeguato alla richiesta.
5. Se la richiesta riesce a passare il controllo del filtro, allora viene attivato il controller: questo sceglie una vista adatta e carica il modello e anche tutte le librerie, le classi aiutanti, le estensioni e gli script che sono necessari per rispondere alla richiesta.
6. Non appena vengono trasmessi tutti i dati rilevanti alla vista, quest’ultima può inoltrarli al browser.
7. Se è attivo un caching, CodeIgniter ferma provvisoriamente i dati in uscita per poter rispondere direttamente a richieste ricorrenti.
I vantaggi del framework CodeIgniter
Con più di 13.000 stelline, CodeIgniter è un progetto di sviluppo GitHub molto stimato e si posiziona al terzo posto tra i framework più popolari. Ma come ogni software, anche CodeIgniter possiede sia vantaggi che svantaggi. Se siete uno sviluppatore web è necessario valutare entrambi prima di scegliere questo framework PHP così leggero. Questi sono i vantaggi dell’applicazione:
- Configurazione semplice: il primo approccio con CodeIgniter è semplice. Gli utenti non si devono occupare a lungo della configurazione del framework, ma possono iniziare praticamente subito con lo sviluppo dell’applicazione che hanno pianificato. La difficoltà si limita fondamentalmente alle impostazioni nel config.php nel percorso application/config/. Gli utenti definiscono un percorso standard per l’accesso via browser, una chiave per la codifica, un nome per i cookie di sessione e le impostazioni per il cross-site-scripting (XSS). È inoltre raccomandabile creare un file .htaccess per rimuovere index.php tramite RewriteRule dal percorso degli URL dell’applicazione. Oltre a ciò è anche indispensabile effettuare la configurazione della connessione al database che inserite nel file database.php.
- Small Footprint: CodeIgniter lascia solamente una traccia minima nel sistema. Il pacchetto per il download del framework pesa 11 MB. Di questi, più di 9 MB sono dedicati all’esaustiva documentazione del software. La dimensione ridotta del codice è quindi causata dal fatto che il sistema di base di CodeIgniter comprende esclusivamente un paio di piccole librerie. Eventuali risorse aggiuntive possono essere caricate successivamente senza problemi a seconda delle necessità.
- Prestazioni elevate: Il sistema di base così leggero fa sì che CodeIgniter, rispetto ad altri framework PHP, possa usufruire di una velocità molto elevata, per la quale ha ricevuto anche i complimenti dell’inventore del PHP Rasmus Lerdorf. Alla Free and Open Source Conference (FrOSCon) del 2008, infatti, Lerdorf ha comunicato che gli piace CodeIgniter, perché è più veloce e più leggero, e si allontana dall’idea comune di framework (“because it is faster, lighter and the least like a framework”).
- URL puliti: CodeIgniter genera automaticamente URL user-friendly e ottimizzati per i motori di ricerca. Al posto di realizzare l’accesso a contenuti web dinamici tramite Query Strings come altri framework PHP, CodeIgniter fa affidamento su un’impostazione basata sui segmenti.
URL con Query String: example.com?controller=news&function=article&id=511
URL con segmenti: example.com/news/article/511.
- Stile di programmazione libero: CodeIgniter si basa sulla libera interpretazione del modello di architettura MVC. Gli sviluppatori non sono tenuti a seguire alcuno stile di programmazione specifico.
- Documentazione dettagliata: CodeIgniter dispone di un’ampia documentazione in lingua inglese, incluso un tutorial per principianti. Oltre a ciò, il codice sorgente è chiaro e commentato precisamente. La documentazione di CodeIgniter si trova sulla pagina web del progetto come guida online ed è disponibile per il download.
- Supporto della community: gli sviluppatori che sviluppano applicazioni sulla base di CodeIgniter possono contare sull’aiuto di altri utenti. Il progetto è seguito da una community molto attiva ed esiste un forum pubblico. Attualmente sono più di 7.300 gli utenti che si scambiano opinioni riguardo all’utilizzo e allo sviluppo del framework in ben 65.000 discussioni.
Svantaggi del framework CodeIgniter
Già prima del passaggio a BCIT lo sviluppo del framework CodeIgniter era a tratti stagnante. Gli sviluppatori che sono alla ricerca di alcune evoluzioni tecnologiche, come sono state ad esempio adottate da framework simili negli anni passati, rimarranno delusi ad aspettarsele da CodeIgniter.
- ORM solo tramite provider terzi: la programmazione orientata agli oggetti (object-relational mapping, ORM) è una tecnica dello sviluppo di software, che permette alle applicazioni di trasferire oggetti scritti con un linguaggio di programmazione orientato all’oggetto come il PHP su un database relazionale. CodeIgniter non supporta l’ORM a livello nativo. La tecnica può però venire integrata tramite servizi offerti da terzi.
- Template engine assente: CodeIgniter si vanta di poter operare senza dover ricorrere a un template engine. Al suo posto il framework offre opzionalmente un semplice parser di template, che può essere considerato un vantaggio. Solitamente l’intervento di un template engine è connesso a un overhead della performance (un tempo aggiuntivo). In aggiunta, oltre al framework va appreso anche l’utilizzo del linguaggio template. Altrimenti un template engine permette di separare la generazione di dati dal codice per la presentazione, facendo sì che si crei un codice sorgente con una struttura molto chiara. Se si attiva un template engine con una sintassi leggera, può decisamente ridurre l’intera estensione del codice dell’applicazione.
- Name spacing assente: grazie a name spaces PHP dà la possibilità di separare il codice di diversi gruppi di applicazione. Gli sviluppatori PHP sfruttano questa feature per evitare conflitti che compaiono nella nomina di classi e funzioni. Capitano, ad esempio, collisioni di nomi tra classi, funzioni, costanti o elementi PHP interni che vengono integrati da servizi offerti da terzi. Finora CodeIgniter non sfrutta questa feature PHP.
- PHP auto loading assente: a partire dalla versione 5, con __autoload() e spl_autoload_register(), il PHP offre due funzioni che permettono di caricare automaticamente definizioni di classi a piacimento. Questa feature non è disponibile per il framework CodeIgniter.
- Meno librerie built-in rispetto ad altri framework PHP: Per via del design così leggero del software che offre, CodeIgniter contiene decisamente meno librerie di altri PHP framework nella sua configurazione finale. Queste comprendono, innanzitutto, i compiti più importanti dello sviluppo web come accessi database, invio di e-mail, la validazione di dati dei formulari, il mantenimento di sessioni oppure le operazioni con XML-RPC. Per i compiti che vanno oltre alle features di base devono essere integrate alcune librerie proprie o risorse offerte da terzi. Un punto che può venire anche interpretato come un vantaggio dagli sviluppatori che ricercano un framework ridotto al minimo essenziale.
CodeIgniter per il lettore frettoloso
La seguente tabella illustra una rassegna dei dati più importanti del framework CodeIgniter:
| CodeIgniter | |
|---|---|
| Sviluppatore | British Columbia Institute of Technology (BCIT) |
| Edizione attuale | Versione 3.1.2 |
| Modello di design | MVC/HMVC, Active Record, Chain of Responsibility |
| Conoscenze richieste | PHP, programmazione orientata all’oggetto (OOP) |
| Linguaggio di programmazione | PHP 5.6 o superiore |
| Licenza | Licenza MIT |
| Supporto database | MySQL (5.1+), Oracle, PostgreSQL, MS SQL, SQLite, CUBRID, Interbase/Firebird, ODBC |
| ORM | Solo tramite servizi offerti da terzi |
| Caching | Sì |
| Template engine | No |
| Name spaces | No |
| PHP auto loading | No |
| URL ottimizzati per i motori di ricerca | No |
| Features per la sicurezza | Cross-Site-Request-Forgery (XSRF), Cross-Site-Scripting (XSS), SQL Injection |
| Testing library | PHP Unit |
In conclusione: a quali progetti si adatta CodeIgniter?
Grazie al suo design compatto e alla sintassi facile e adatta ai principianti, CodeIgniter è l’ideale soprattutto per programmatori in erba. Chi ha già accumulato esperienze nel campo dello sviluppo web dinamico sulla base del linguaggio PHP, se la caverà in breve tempo anche con il framework leggero basato su PHP. Anche gli sviluppatori web apprezzano la flessibilità che un framework così ridotto alle funzionalità di base come CodeIgniter mette a disposizione. Chi ha l’intenzione di optare per CodeIgniter dovrebbe però innanzitutto essere pronto da una parte a prendere confidenza con il modello di architettura MVC e dall’altra a rinunciare a un template engine e all’ORM nativo. Nonostante la dimensione ridotta del codice, il PHP framework è adatto sia per progetti piccoli che per quelli più grandi.