CodeIgniter infatti, tramite la classe Routing, si occupa di leggere l’URL digitato e indirizzare all’apposito controller il metodo da eseguire. Ad esempio, digitando l’indirizzo http://www.dominio.com/index.php/nome_controller/nome_metodo/ CodeIgniter andrà a richiamare il controller nome_controller ed eseguirà il metodo nome_metodo. Se invece viene omesso nome_metodo verrà richiamato il metodo di default chiamato index.

Dal punto di vista del codice, un controller non è altro che una classe PHP che eredita dalla classe nativa Controller. Pertanto la sintassi base sarà:

class Mia_classe extends Controller {
    function Mia_classe() { //questo è il costruttore
        parent::Controller(); //richiamo il costruttore della classe “Controller”
    }

    function index() {
        //funzione richiamata di default
    }

    function mia_funzione() {
        //metodo personalizzato
    }
}

i controller vanno di norma salvati nella cartella /system/application/controllers, mentre il nome del file dovrà coincidere col nome della classe, quindi nell’esempio precedente questo dovrà chiamarsi mia_classe.php – Notare l’eliminazione delle maiuscole richiesta dal framework.

Tornando alla nostra applicazione, dato che abbiamo tre entità in gioco avremo bisogno di tre file separati. Ciò non è la regola, in quanto i controller vanno intesi più che altro come azioni da compiere. Nel nostro caso però, dato che andremo ad operare ogni volta su un elemento preciso in maniera abbastanza indipendente, ho preferito separarli in tre controller distinti anziché uno unico.

Partiamo dal controller delle tipologie (che sarà analogo a quello degli stati).

Prendendo come spunto il modello qui sopra, il nostro controller per gli stati sarà del tipo:

class Statuses extends Controller {
    function Statuses() {
        parent::Controller();
        $this->load->model(‘status_model’);
    }

    function index() {
        //funzione richiamata di default
    }
}

Come vedete nel costruttore Statuses() vado a caricare il modello status_model che mi servirà all’interno del controller.

Ora andiamo a popolare il metodo index() che ci servirà per la lista completa degli stati. Per farlo aggiungiamo:

$data[‘statuses’] = $this->status_model->get();
$this->load->view(‘list_statuses’, $data);

La prima riga si occupa di eseguire il metodo get del modello status_model e a salvarne l’output nell’array $data. Nella seconda riga invece andiamo a caricare la vista list_statuses passando i dati da visualizzare. CodeIgniter andrà a cercare la vista list_statuses.php all’interno della cartella /system/application/views. Vedremo in seguito come realizzare la vista, ma per quanto riguarda il Controller abbiamo già ottenuto quello che ci serve.

I prossimi metodi che ci servono sono quelli per interagire col sito. Infatti abbiamo previsto la possibilità di aggiungere, modificare o rimuovere stati direttamente dal sito senza dover accedere al database.

Presupponiamo già di avere un form che invii tramite post i campi necessari (andremo a realizzarlo in una delle viste). Il nostro metodo che chiameremo add() sarà:

function add() {
    if ($this->input->post(‘submit’) {
        //ho fatto il submit...
        $insert[‘name’] = $this->input->post(‘name’);
        $this->status_model->add($insert);
        return $this->index();
    } else {
        //non ho fatto il submit quindi mostro il form...
        $this->load->view(‘add_status’);
    }
}

Innanzitutto vedo se ho già fatto il submit o se invece devo mostrare il form per l’inserimento. Nel primo caso leggo i dati tramite $this->input->post('nome') che è il metodo offerto dalla libreria Input di C.I. per leggere i dati in POST, richiamo il metodo add() del modello per seguire l’inserimento. Una volta concluso mostro la lista degli articoli richiamando il metodo di default $this->index()

La funzione edit() è molto simile, con la differenza che dovendo modificare un preciso stato dovrò specificarlo tramite id. Per farlo basta passare quest’ultimo come parametro al nostro metodo. Nel browser ciò è possibile nella forma: http://www.dominio.com/index.php/mio_controller/metodo/parametro1/parametro2/ etc…

Il metodo diventa quindi:

function edit($id) {
    if ($this->input->post(‘submit’) {
        //ho fatto il submit...
        $insert[‘name’] = $this->input->post(‘name’);
        $this->status_model->edit($insert, $id);
        return $this->index();
    } else {
        //non ho fatto il submit quindi mostro il form...
        $data[‘status’] = $this->status_model->get_single($id);
        $this->load->view(‘add_status’, $data);
    }
}

Come vedete l’unica differenza rispetto all’inserimento sta che nel metodo edit() del modello devo passare anche l’id dell’elemento da modificare. Devo inoltre pre-popolare il form con i valori già esistenti. Posso farlo tramite il metodo get_single($id) del nostro modello, che ci permette di leggere un singolo stato e passarne i dati alla vista.

L’ultimo metodo è quello destinato alla cancellazione di uno stato, ed è molto semplice:

function delete($id) {
    $this->status_model->delete($id);
    return $this->index();
}

Come avrete sicuramente visto non viene effettuato nessun controllo sulla validità dei dati. Questo però sarà facilmente integrabile in un secondo momento tramite ulteriori controlli e la libreria Validation presente in CodeIgniter.

Il controller Types sarà identico a quanto appena visto, con l’unica differenza di nomenclatura tra stati e tipi. Basterà quindi fare copia-incolla dei files e modificare quanto serve.

Anche il controller relativo agli items sarà molto simile, con la differenza che avremo più campi da gestire (non solo il nome) e avremo bisogno di tutti e tre i modelli. Il controller completo è il seguente:

class Items extends Controller {

    function Items() {
        parent::Controller();
        $this->load->model('item_model');
        $this->load->model('type_model');
        $this->load->model('status_model');
    }

    function index() {
        //lista degli elementi nel database
        $data['items'] = $this->item_model->get();
        $this->load->view('list_items', $data);
    }

    function add() {
        if ($this->input->post('submit')) {
            $insert['name']             = $this->input->post('name');
            $insert['code']             = $this->input->post('code');
            $insert['description']      = $this->input->post('description');
            $insert['position']         = $this->input->post('position');
            $insert['type_id']          = $this->input->post('type_id');
            $insert['status_id']        = $this->input->post('status_id');
            $insert['about_the_status'] = $this->input->post('about_the_status');

            $this->item_model->add($insert);
            return $this->index(); //torno all'indice...
        } else {
            $data['types']    = $this->type_model->get();
            $data['statuses'] = $this->status_model->get();
            $this->load->view('add_item', $data);
        }
    }

    function edit($id) {
        if ($this->input->post('submit')) {
            $insert['name']             = $this->input->post('name');
            $insert['code']             = $this->input->post('code');
            $insert['description']      = $this->input->post('description');
            $insert['position']         = $this->input->post('position');
            $insert['type_id']          = $this->input->post('type_id');
            $insert['status_id']        = $this->input->post('status_id');
            $insert['about_the_status'] = $this->input->post('about_the_status');

            $this->item_model->edit($insert, $id);
            return $this->index(); //torno all'indice...
        } else {
            $data['item']     = $this->item_model->get_single($id);
            $data['types']    = $this->type_model->get();
            $data['statuses'] = $this->status_model->get();
            $this->load->view('edit_item', $data);
        }
    }

    function delete($id) {
        $this->item_model->delete($id);
        return $this->index();
    }
}

Anche se più lungo, il concetto è il medesimo dei precedenti. Vorrei soffermarmi semplicemente sulle istruzioni

$data[‘types’] = $this->type_model->get();
$data[‘statuses’] = $this->status_model->get();

presenti sia nel metodo per l’inserimento che per quello per la cancellazione. In pratica andiamo a prepararci in due array l’elenco degli stati e delle tipologie disponibili nel nostro database. Questo ci serve per realizzare delle comode dropdown nei form per i riferimenti esterni. Quando vedremo in dettaglio le viste capiremo meglio come andremo a utilizzarlo.

Nella prossima puntata vedremo in dettaglio le viste, completando il primo step e potendo far funzionare una prima basilare applicazione. In seguito, come già accennato, vedremo come gestire la validazione dei dati.

Puntate precedenti:

1. Introduzione
2. Il database
3. I modelli
4. L’applicazione

La novità più rilevante è la nuova classe Form Validation che presenta diverse novità rispetto alla precedente.

In pratica viene semplificato e velocizzato il modo in cui si impostano i campi, le label e le regole. Anziché usare i metodi $this->validation->set_fields() e $this->validation->set_rules() si può utilizzare un unico comando per ciascun input — $this->form_validation->set_rules(NOMECAMPO, LABEL, REGOLA); — oppure impostare direttamente un array multidimensionale, per tutti i campi, in una sola volta. Ulteriore vantaggio è la possibilità di impostare le regole di validazione su un file di configurazione esterno, snellendo quindi il codice da usare nel controller.

Anche il codice lato vista, per visualizzare gli errori, beneficia dell’introduzione di appositi helper per visualizzare i messaggi di errore e per ripopolare il form. Anziché dover utilizzare i metodi $this->validation->nomecampo e $this->validation->nomecampo_error sarà sufficiente utilizzare le funzioni set_value('nomecampo') e form_error('nomecampo')

Per tutti i dettagli e le altre novità vi rimando alla pagina di annuncio e al relativo change log

L’installazione è semplicissima se avete un webserver php attivo con mysql configurato. Provate visitando l’indirizzo http://localhost/ (altrimenti esistono ambienti preconfigurati come XAMPP per windows o MAMP per macintosh molto facili da installare).

Innanzitutto scaricate il file contenente tutto il necessario: [Scarica]

Create poi una cartella (io l’ho chiamata “homeDB”) all’interno del vostro “localhost” (dove avete le cartelle dei vostri progetti in php, per intenderci) e scompattate all’interno il file zip. Quest’ultimo contiene, oltre al framework e all’applicazione, un file SQL per creare le tabelle necessarie (eseguite la query all’interno di phpMyAdmin o della vostra interfaccia MySQL preferita).

Ora non resta che modificare la configurazione dell’applicazione per adattarla al vostro ambiente. Per prima cosa aprite il file config.php all’interno di [vostraCartella]/system/application/config/ e modificate la riga $config['base_url'] = "http://127.0.0.1/homeDB/"; con la vostra cartella al posto di homeDB.

In secondo luogo bisognerà indicare i nuovi parametri di connessione al database. Per farlo aprite database.php nella stessa cartella e modificate in fondo alla pagina i parametri con quelli corretti.

A questo punto tutto dovrebbe essere configurato correttamente e dovreste già poter vedere l’applicazione funzionante visitando l’indirizzo http://localhost/[vostraCartella]. Potete creare qualche record fittizio per provare il tutto: vi suggerisco di partire dalle tipologie e dagli stati dato che sono campi obbligatori. Potete anche vedere, nell’inserimento degli articoli, la libreria Validation fornita direttamente da CodeIgniter (provate a creare un articolo vuoto).

Nei prossimi giorni vedremo gli altri elementi dell’applicazione, ovvero i controller e le viste, nonché l’utilizzo di helper e librerie.

Edit: ho messo on-line una demo di questo primo abbozzo di applicazione a questo indirizzo se volete provarla “dal vivo”. Mi raccomando non scrivete oscenità

Non mi dilungherò nel spiegare la struttura di CodeIgniter o in generale il pattern MVC. Per capire la struttura del primo e il significato del secondo vi consiglio di visitare la guida completa di codigniter e la pagina di wikipedia rispettivamente.

Vi ricordo soltanto che dobbiamo lavorare sempre all’interno della cartella /system/application.

Prima di cominciare dobbiamo però dire a CodeIgniter di precaricare la libreria “Database” dato che ci servirà pressoché dappertutto. Per farlo basta modificare il file /config/autoload.php modificando la riga

$autoload['libraries'] = array();

con

$autoload['libraries'] = array('database');

Fatto questo vediamo quindi i modelli della nostra applicazione.

il Modello “Item_model”

Come regola generale nominerò i modelli nella forma Nomemodello_model, quindi il nostro primo modello sarà Item_model e dovrà estendere la classe predefinita per i modelli di CodeIgniter, chiamata appunto “Model”:

<?php
class Item_model extends Model {
    ...
}
?>

All’interno del modello andremo a realizzare i vari metodi che ci servono per operare col nostro database. Ci serviranno i metodi per leggere gli elementi, per aggiungerli, modificarli o cancellarli. Partiamo dal metodo per leggerli:

function get() {
    $query = $this->db->get('items');
    return $query->result_array();
}

Come vedete abbiamo usato la libreria “Database” tramite $this->db e il metodo “get” che accetta come parametro il nome della tabella da cui prelevare i dati. Abbiamo assegnato il risultato di questo metodo alla variabile $query, ma per ottenere i risultati veri e propri dobbiamo richiedere i dati tramite il metodo result_array() che restituisce appunto un array di risultati.

Se avessimo voluto avremmo potuto usare il metodo result() che restituisce invece un oggetto contenente i risultati. Ci sono altri metodi risponibili, ad esempio row() e row_array() che restituiscono l’ultima riga. Fate riferimento alla guida per tutti i dettagli.

Tornando al nostro metodo “get”, questo ritornerà quindi un array con tutti gli elementi nel nostro database. Come ricorderete però sono presenti due chiavi esterne relative al tipo e allo stato, quindi se vogliamo avere tra i risultati anche queste informazioni dobbiamo “unire” queste tabelle tramite il metodo “join”:

function get() {
    $this->db->from('items');
    $this->db->join('types', 'items.type_id = types.id');
    $this->db->join('statuses', items.status_id = statuses.id');
    $query = $this->db->get();
    return $query->result_array();
}

Come potete vedere “join” accetta come primo parametro il nome della tabella e come secondo parametro la relazione tra i campi. Ho anche aggiunto il comando “from” per maggior chiarezza. Avrei infatti potuto ometterlo ed indicare la tabella “items” direttamente nel metodo “get”.

Naturalmente questo metodo non gestisce ancora né la paginazione né nessun tipo di ricerca o filtraggio, tuttavia avremo modo più avanti, in base alle necessità che ci occorrono, di provvedere ad integrare le funzionalità di cui avremo bisogno.

Aggiungiamo ora il metodo per aggiungere un elemento. Dato cheil metodo proposto dalla libreria “Database” accetta come parametro un array associativo con campi e valori, il nostro metodo ugualmente accetterà un array:

function add($item) {
    return $this->db->insert('items', $item);
}

Come potete notare questo metodo non aggiunge niente al metodo predefinito di CodeIgniter, tuttavia se in futuro avremo bisogno di effettuare qualche intervento sui dati prima di inserirli avremo modo di aggiungere le istruzioni, cosa impossibile da fare se avessimo usato direttamente la classe “Database”.

Per la cancellazione e la modifica i metodi sono molto simili:

function delete($id) {
    $this->db->where('id', $id);
    return $this->db->delete('items');
}

function edit($item, $id) {
    $this->db->where('id', $id);
    return $this->db->update('items', $item);
}

Come vedete ho utilizzato “where” dato che andremo sempre a cancellare o modificare un singolo elemento, identificato tramite l’id.

Ricapitolando quindi la nostra classe al completo sarà

<?php
Class Item_model extends Model {
    function get() {
        $this->db->from('items');
        $this->db->join('types', 'items.type_id = types.id');
        $this->db->join('statuses', items.status_id = statuses.id');
        $query = $this->db->get();
        return $query->result_array();
    }
    function add($item) {
        return $this->db->insert('items', $item);
    }
    function delete($id) {
        $this->db->where('id', $id);
        return $this->db->delete('items');
    }
    function edit($item, $id) {
        $this->db->where('id', $id);
        return $this->db->update('items', $item);
    }
}
?>

I modelli “Status_model” e “Type_model”

Per quanto riguarda i modelli dei tipi e degli stati avremo più o meno le stesse funzionalità. Riporterò quindi direttamente il codice delle classi direttamente:

Class Status_model extends Model {
    function get() {
        $query = $this->db->get('statuses');
        return $query->result_array();
    }
    function add($status) {
        return $this->db->insert('statuses', $status);
    }
    function delete($id) {
        $this->db->where('id', $id);
        return $this->db->delete('statuses');
    }
    function edit($status,$id) {
        $this->db->where('id', $id);
        return $this->db->update('statuses', $status);
    }
}

E per i tipi:

Class Type_model extends Model {
    function get() {
        $query = $this->db->get('types');
        return $query->result_array();
    }
    function add($type) {
        return $this->db->insert('types', $type);
    }
    function delete($id) {
        $this->db->where('id', $id);
        return $this->db->delete('types');
    }
    function edit($type,$id) {
        $this->db->where('id', $id);
        return $this->db->update('types', $type);
    }
}

Ora che abbiamo il codice dobbiamo però salvarlo in qualche file. CodeIgniter ha una suddivisione molto logica dei vari files ed ogni classe ha la propria cartella: i modelli andranno in models, i controlli in controllers e via dicendo.

Per quanto riguarda i nomi dei files, per permettere a CodeIgniter di caricare automaticamente i files necessari basterà utilizzare lo stesso nome, però in minuscolo, del nostro modello. Ad es. “Item_model” dovrà chiamarsi item_model.php e via dicendo.

Questi sono quindi i modelli base da cui partire. Nel prossimo step vedremo come utilizzarli attraverso i controller. Come già accennato andremo probabilmente ad integrare alcune funzionalità nei nostri modelli in base alle necessità (ad esempio per implementare la ricerca). Il vantaggio di sviluppare su un framework o comunque con un pattern MVC è quello di poter intervenire nelle varie entità in gioco in maniera indipendente e trasparente. Paradossalmente se un giorno volessimo ad esempio cambiare totalmente strada e rimpiazzare il database con un file di testo, ci basterebbe cambiare opportunamente i modelli (o addirittura la sola libreria “Database”) e il resto dell’applicazione non se ne accorgerebbe…

Alla prossima!

Nel capitolo introduttivo ho descritto genericamente il funzionamento e le entità in gioco, ora vediamo più concretamente come sarà strutturata definendo le tabelle del nostro database.

Partiamo definendo le entità e di conseguenza il database che ci serve.
Ho individuato principalmente tre elementi in gioco: Item (gli elementi che catalogheremo), Type (il tipo di elementi – ad es. cd, vhs, dvd…), Status (i possibili stati – ad es. in archivio, prestato, perduto, danneggiato, etc)

Items

Ho chiamato “Item” l’oggetto del nostro archivio, sia esso un cd, una cassetta o qualsiasi altro tipo di elemento che vogliamo catalogare.
La tabella nel nostro DB, che chiameremo appunto “items” conterrà queste colonne:

• id (INT 7)
• name (VARCHAR 255)
• code (VARCHAR 255)
• description (TEXT)
• position (TEXT)
• type_id (INT 7)
• status_id (INT 7)
• about_the_status (TEXT)

In particolare code rappresenta un eventuale codice identificativo, description una descrizione indicativa del contenuto (ad es. i titoli degli album all’interno di una compilation mp3), position il luogo dove l’abbiamo riposto (ad es. “porta cd N°1 pagina 23 scomparto 11″), type_id la chiave esterna del tipo, status_id la chiave esterna dello stato corrente e about_the_status un commento sullo stato corrente (ad es. “prestato a Mario a Natale”).

Types

Nella tabella “types” andremo ad inserire le tipologie di oggetti che andremo a gestire, eventualmente con la possibilità di indicarne di nuovi -ad es. quando compreremo qualche Blue-ray .
I campi quindi saranno per adesso soltato due:

• id (INT)
• name (VARCHAR 255)

Statuses

La tabella “statuses” sarà identica alla tabella “types” ma conterrà gli stati possibili che potranno assumere i nostri elementi:

• id (INT)
• name (VARCHAR 255)

Ora che abbiamo definito le tabelle necessarie del nostro database, possiamo procedere alla stesura dell’applicazione. Nel prossimo step comincierò a lavorare su CodeIgniter, per prima cosa definendo i modelli, e cioè le rappresentazioni nel framework delle nostre entità. Più concretamente, tramite i modelli compiremo tutte le interazioni con le tabelle del DB. Nel nostro codice quindi non dovremo mai dialogare direttamente col database, useremo sempre e soltanto i metodi che andremo a definire per ciascun modello. Giusto per darvi un assaggio, useremo una sintassi del tipo $this->item_model->get_all();

Alla prossima!

Mi è venuta quindi l’idea malsana di stendere un piccolo db per gestire il proprio archivio di cd, dvd e simili. Ovviamente penserete a cose tipo Bento o peggio ancora Access. In realtà, dato che vorrei costringere un po’ tutta la famiglia a organizzare meglio le cose ho pensato di creare una web-application accessibile on-line, in modo che ciascuno possa intervenire dal proprio pc (o mac ) lavorando direttamente sul web.

E quale occasione se non questa per buttare giù un piccolo tutorial passo passo sul framework CodeIgniter? Ecco i dettagli del progetto che andrò a realizzare:

Innanzitutto il software gestirà semplicemente un elenco di supporti di vario tipo (cd, dvd, vhs etc…). Ci sarà ovviamente la possibilità di specificare per ogni record un nome, una descrizione sul contenuto, una categoria, uno spazio per indicare dov’è riposto ed eventualmente un codice (se siete maniaci e avete già inventariato le vostre cose…)

Altra cosa interessante sarà la possibilità di impostare uno stato, ad esempio “prestato” (in tal caso a chi, quando e perché) oppure “perso” etc. Vi permetterà di tenere sotto controllo quello che succede nel vostro archivio, e soprattutto sapere con certezza che fine ha fatto quel cd che non trovate più e che vi ricordate di aver dato a qualcuno ma non ricordate chi… non ci saranno più scuse!

L’interfaccia sarà molto semplice: ci sarà la pagina di elenco – con la possibilità di vedere gli articoli per tipologia e la possibilità di ricercare nella propria libreria – e la pagine di creazione e di modifica di un articolo col consueto form. In un secondo tempo vedremo di integrare qualche funzionalità Ajax tramite jQuery per dare quel tocco web 2.0 che ormai è un must.

Nella prossima puntata vedremo in dettaglio le entità in gioco e stenderemo la struttura del database. Nel frattempo se avete suggerimenti lasciate un commento!