Introduzione a CActiveRecord

Come sappiamo uno degli aspetti principali di una web application è l'utilizzo di una base di dati. Yii ci consente di interagire con differenti tipi di database: MySql, MsSql, Oracle ecc.. L'utilizzo di una base di dati invece che un'altra, avviene in modo del tutto trasparente per l'utente. Yii infatti, utilizza la libreria PDO di PHP per interagire con i dati. Quindi indipendentemente dalla base di dati, il model, presenterà sempre i medesimi metodi che ci consentiranno di interagire con una tabella del nostro database.

Prima di addentrarci nel vero utilizzo di active record è bene ricordare che deve essere definita, all'interno del file di configurazione, una connessione al database. Infatti, anche se avviene in modo del tutto trasparente all'utente, il model farà uso di quella connessione.

Come al solito utilizziamo il file di esempio che abbiamo creato inizialmente mediante il modulo gii. I model si trovano appunto nella posizione application.models. La prima cosa che possiamo notare, e che avevamo già anticipato, è che il model è una classe che estende CActiveRecord il cui nome è rappresentato dal nome della tabella alla quale è relazionato nel formato camel. Il nome del file corrisponde al nome della classe. In realtà è possibile utilizzare per la classe, e quindi anche per il nome del file, nomi diversi rispetto alla tabella. Potrebbe tornare utile quando in un database, abbiamo delle tabelle , raggruppate secondo una certa logica, mediante un prefisso. In questo caso , almeno di omonimie, si potrebbe preferire di utilizzare un nome senza prefisso. Se scegliamo questa strada dobbiamo però dire al model a quale tabella ci riferiamo mediante l'override del metodo tableName

public function tableName()
{
	return "nomeDellaTabella";
}

Nel costruttore del nostro model c'è solamente un richiamo al costruttore padre, al quale viene passato il nome della nostra classe.

Il primo metodo interessante è senza dubbio attributeLabels() che è pubblico. Come potete facilmente intuire questo metodo fornisce le etichette dei campi della nostra tabella. Probabilmente quando abbiamo progettato il database, abbiamo utilizzato per i campi nomi composti legati tra loro mediante il simbolo dell'underscore. Se lato database la cosa è funzionale lo è molto meno quando si tratta di presentare il contenuto all'utente. Questo metodo ci consente, mediante un array di tipo associativo, di collegare ad ogni campo della tabella una etichetta.

Uno dei metodi più importanti all'interno del nostro model è rules(). Prima di scendere nel dettaglio dobbiamo comprendere cosa si intende per scenario. In modo abbastanza grossolano, possiamo dire che uno scenario indica le iterazioni che intercorrono tra l'utente e il sistema. Uno scenario può essere pensato appunto come una serie di azioni che portano ad un determinato stato del sistema. Si immagini l'operazione di inserimento di un nuovo utente. Ci sono varie fasi(sintetizzando):

• Presentazione della schermata di inserimento
• Ricezione, valutazione e memorizzazione eventuale dei dati
• Messaggio di risposta all'utente

Quello appena descritto potrebbe rappresentare lo scenario di inserimento.

Fatta questa premessa, capire il funzionamento del metodo rules diviene semplice. Questo metodo restituisce un array di array. Ogni singolo array presenta determinati valori. Il primo tra questi è la lista dei campi, separati con la virgola, della tabella a cui deve essere applicata la regola. Successivamente troviamo il "validatore", che costituisce di fatto la vera regola che sarà applicata ai campi e, per finire, lo scenario sottoforma di chiave => valore. La chiave è sempre on.

La documentazione ufficiale è sicuramente di grande aiuto nel fornire tutti i possibili valori per le regole da applicare. In questa guida diciamo solo che il validatore può essere:

• Un alias (boolean, email, requier, ecc),di significato immediato, delle classi di validazione.
• Il nome di una classe che estende la classe CValidator.
• Il nome di un metodo del nostro model.

Qualora ad uno stesso campo si debbano applicare più di una regola, è sufficiente creare tanti array per quante regole occorrono.

public function rules()
	{
		return array(
		array('id', 'required', 'on'=>'update'),
		array('id', 'numerical', 'integerOnly'=>true),
		array('user, password, mail', 'length', 'max'=>255),
		array('data_iscrizione', 'safe'),
		array('id, user, password, mail, data_iscrizione', 'safe', on'=>'search'),
		);
	}

Nel nostro caso, il campo id, oltre ad essere obbligatorio, nello scenario update, deve essere necessariamente un numero e la lunghezza massima consentita per i campi user, password e mail è 255 caratteri. Queste informazioni son state generate mediante il modulo gii. Nulla ci vieta di modificarle a nostro piacimento. Il modulo gii preleva le informazioni del metodo rules, come ad esempio la chiave primaria, la lunghezza e l'obbligatorietà dei campi, dall'interno dello schema della tabella.

Se modifichiamo lo schema della tabella dobbiamo ricordarci quindi di apportare le necessarie modifiche al model, onde evitare errori inaspettati. Uno dei metodi più semplici per aggiornare il model è quello di chiedere a gii di rigenerare il model stesso. Prima di creare fisicamente il file ci mostrerà le differenze con il file che abbiamo. A quel punto ci basterà intervenire per le eventuali correzioni sul nostro model. Qualora le modifiche allo schema siano minime il consiglio è quello di non passare dal modulo gii ma di apportare le modifiche in modo manuale.

Interessante invece è l'ultimo caso quello dello scenario search. In quel caso gli attributi vengono definiti sicuri , safe appunto, per poterli utilizzare. Un attributo non definito in questa regola non può essere utilizzato per la ricerca.