Sei sulla pagina 1di 16

- Scaricare un archivio dal sito

- Decomprimerlo nella cartella principale


- Creare database in phpmyadmin
- Configurare file di configurazione config/db.php

Si va nella cartella dove si vuole scaricare il framework e si scrive:

composer create-project --stability=dev yiisoft/yii2-app-basic

Composer inizierà, così, lo scaricamento:

Ci potrà mettere un po’, perché i pacchetti da installare sono un bel po’


Può capitare che, durante lo scaricamento, Composer chieda
<<Do you want to remove the existing VCS (.git, .svn..) history? [Y,n]?>>
ossia (letteralmente) <<Vuoi rimuovere la cronologia VCS (.git, .svn ..) esistente? [S, n]?>>
che, sostanzialmente, significa che, se il pacchetto è provvisto di uno storico VCS (per esempio dei commit
git), questo verrà eliminato e resterà solo il pacchetto scaricato. Se non si sta seguendo l’avanzamento del
progetto con il fornitore e non si è interessati a seguirlo od a revisionare specifiche precedenti versioni non
si ha motivo di mantenere l’eventuale VCN. In tal caso, si potrà rispondere Y.

Dopo aver risolto questa questione l’operazione sarà chiusa rapidamente

Una volta fatto questo, si può costruire un un database


La struttura di file e cartelle di Yii2.0

Basic
I modelli

Quando si crea un modello, si dichiara (anzitutto) il namespace a cui dovrà appartenere e poi si richiede
l’utilizzo delle classi Yii e Model, di cui Model è nel namespace yii\base\

<?php

namespace app\models;

use Yii;
use yii\base\Model;

Fatto questo, si potrà definire la classe.

Per convenzione i nomi delle classi dei modelli usano una sintassi di differenziazione, tra maiuscolo e
minuscolo, particolare in cui i termini iniziano tutti con le maiuscole e, quando sono termini composti di più
termini accorpati, ogni termine inizia con una maiuscola, per indicare che si tratta di un termine in a parte
componente il nome (es: ClientiLocali, PagamentiFornitori, ecc ).

Si deve creare una classe che estenda la classe Model.

Il nome della classe e del file php che la contiene devono essere identici.

In sintesi, quindi:

definizione del namespace

dichiarazione dei namespace che si vuole utilizzare

definizione della classe che estende Model

<?
namespace app\models;

use Yii;
use yii\base\model;

class NomeClasse extends Model 
{

?>
Oltre ad estendere Model, un modello può estendere anche una classe modello, che a sua volta deriva da
Model. Per esempio, il modello standard (preconfezionato) User di Yii estende ActiveRecord.
Una volta definito così, poi si potrà usare (in un file in cui possa servire) in un modo tipo:

$model = new app\models\NomeClasse;

Per esempio, se vogliamo creare un modello che chiamiamo Operators, per esempio per la gestione degli
operatori di un certo sistema, potremmo scrivere:

<?
namespace app\models;

use Yii;
use yii\base\model;

class Operators extends Model 
{

    
}

?>
E, poi quando dovesse servire, potremmo scrivere:

$model = new app\models\Operators;
od anche chiamando la variabile oggetto in altro modo, come per esempio:

$operator = new app\models\Operators;
Dentro la classe si possono definire diverse variabili, funzioni ed oggetti.

Proprietà (od Attributi)


Le variabili pubbliche non statiche della classe sono dette proprietà od attributi.

In pratica in uno schema simile

<?
namespace app\models;
use Yii;
use yii\base\model;
class NomeClasse extends Model 
{
  public $var1;
    public $var2;
    public $var3;  
}
?>
$var1, $var2 e $var3 sarebbero attributi e sarebbero raggiungibili poi, una volta dichiarata una variabile
$model ed instanziato con essa l’oggetto NomeClasse, con i percorsi:

$model->var1 , $model->var2 e $model->var3


od anche con
$model['var1'] , $model['var2'] e $model['var3']

Gli attributi così definiti sono anche reperibili come celle dell’array attributes dell’oggetto
$nome_modulo->attrubutes
Per esempio, riprendendo l’esempio del modello Operators, aggiungiamo le variabili $name, $surname ed
$email:
<?
namespace app\models;
use Yii;
use yii\base\model;
class Operators extends Model 
{
    public $name;
    public $surname;
    public $email;    
}
?>
Una volta creato un file Operators.php nella apposita cartellina \models\, con all’interno il codice suddetto,
poi in una qualunque views (od altri file che necessitino di usare questo modello) potremmo scrivere:
    $model = new app\models\Operators;
    $model->name = 'Mauri';
    echo $model->name;
Od anche
    $model = new app\models\Operators;
    $model->name = 'Mauri';
    echo $model['name'];
Creare un oggetto, nella variabile $model, che sia di tipo app\models\Operators, gli conferisce le tre
variabili pubbliche suddette ($name, $surname, $email ) come, appunto, proprietà (od attributi).
Si verranno a definire anche le celle dell’array $model->attrubutes; dato che ci sono 3 attributi l’array sarà
di 3 celle, come potremo verificare con la funzione count:
echo count($model->attrubutes) darà come risultato, in questo caso, 3.
Possiamo accedere agli attributi di un oggetto con la freccetta -> seguita dal nome dell’attributo oppure
usando l’oggetto come fosse un array in cui il nome dell’attributo è da usarsi come la chiave.
Ovviamente, se l’attributo è stato definito nella classe allora ESISTE e, se viene utilizzato l’utilizzo in se non
causerà errori. Se invece si dovesse tentare di utilizzare attributi che non esistono, perché non sono stati
definiti nella classe, verrà restituito un errore all’apertura della view:
Comparirà un errore del tipo “Unknown Property” riferito alla classe usata, con una scritta del tipo
“Getting unknown property: app\models\NOME CLASSE::NOME PROPRIETA’ SCRITTO MALE”.
Per esempio, se provassimo ad usare in un oggetto della classe app\models\Operators una proprietà
inesistente, per esempio scrivessimo
    $model = new app\models\Operators;
    $model->name = 'Mauri';
    echo $model['namexx'];
non esistendo una proprietà chiamata “namexx”, verrà restituito un errore di questo tipo:

in realtà, più sotto compariranno anche altri errori (circa 12, ma sostanzialmente dipendono tutti da questo,
almeno in riferimento a questo errore dovrebbero esserci).
Le etichette delle proprietà/attributi
Ogni campo di un modello ha per default una etichetta assegnata (che poi la si utilizzi o meno è
indifferente). Queste etichette, in generale, sono i nomi dei campi così come possono (normalmente)
essere mostrati all’utente all’interno di certe view.
Non è detto che sia necessario o si debba o si possa mostrare sempre il nome di un campo all’utente in una
view, alcuni campi non sono neanche resi noti agli utenti, talvolta.
Generalmente, vengono utilizzate poi nei moduli di inserimento/modifica/registrazione/login/ecc..
In tali moduli, infatti, questi campi possono essere elencati di fianco ai box ove andranno inseriti.
Per impostazione di default, è automaticamente generata (però) una etichetta per ogni campo.
Di default l’etichetta corrisponde al nome del campo, però con la prima lettera maiuscola; tuttavia, ogni
etichetta può essere modificata.
In ogni istante si può accedere al nome di una etichetta di un campo attraverso il metodo getAttributeLabel
della classe Model, quindi presente in ogni modello.
Es:
    $model = new app\models\Operators;
    echo $model->getAttributeLabel('name');
Se non preventivamente modificato, questo produrrà come output la stringa “Name”.
Se ridefiniamo la funzione attributeLabels() possiamo creare le associazioni tra i nomi dei campi e le
etichette
public function attributeLabels()
    {
        return [
            'name' => 'Nome',
            'surname' => 'Cognome',
            'email' => 'E-Mail'
        ];
    }
Per le app multipilingua si può usare la funzione statica di traduzione \Yii::t() per le etichette degli
attrubuti/proprietà (nello specifico \Yii::t($section, $text) traduce sostituisce il testo $text riferito alla
sezione $section – una categorizzazione per settori – , in quello della lingua selezionata ) e potremmo
scrivere
<?
namespace app\models;
use Yii;
use yii\base\model;
class Operators extends Model 
{
    public $name;
    public $surname;
    public $email;    

    public function attributeLabels()
    {
        return [
            'name' => \Yii::t('app', 'Nome'),
            'surname' => \Yii::t('app', 'Cognome'),
            'email' => \Yii::t('app', 'E-Mail')
        ];
    }
}
?>
Scenari:

uno scenario è sostanzialmente uno stato di un modello in cui il comportamento, alcune regole, in alcune
cose, possono cambiare. In ogni modello è presente una proprietà, di tipo stringa, che si chiama scenarios e
che, di norma, contiene la stringa “default”.

Se dichiariamo, in una vista qualsiasi, un modello e stampiamo con echo il suo scenario, salvo
comportamenti inconsueti, dovrebbe stampare la scritta “default”.

$model = new User;


$model->scenario;

Dovrebbe produrre, sulla pagina, la scritta

Default

Come vedremo, si possono definire dei controlli e dei comportamenti (lo vedremo poco più avanti) e questi
possono essere differenziati per scenario.

Quando si definisce un modello si possono definire delle costanti, che rappresenteranno i vari scenari.
Per esempio in un modello Users (che si riferisce alla gestione degli utenti) lo scenario “Registrazione” usa
regole diverse di gestione dei campi, rispetto allo scenario “Login”, perché magari i campi RICHIESTI,
NECESSARI, sono diversi: lo scenario Login, magari, richiederà solo username e password, mentre la
registrazione richiederà anche nome, cognome, magari anche email od indirizzo.

Possono cambiare anche le regole di validazione dei campi, od altre cose.

Vediamo come creare degli scenari.


Creiamo una classe di un modello, per esempio un modello chiamato User; deriviamo User da ActiveRecord

<?
namespace app\models;
use yii\db\ActiveRecord;
class User extends ActiveRecord
{
  
}
?>

Adesso creiamo in User due costanti, che indicheranno ben due scenari:
SCENARIO_LOGIN che porremo pari a “login” e SCENARIO_REGISTER che porremo pari a “register”.
In pratica la proprietà scenarios di User potrà essere, quindi:
“Default”, “login” o “Register”.
A questo punto, negli scenari, i campi interessati potrebbero essere diversi: in uno scenario potrebbero
essere utili alcuni campi ed alcune regole ed un un altro altre, come per esempio lo scenario “register” e
“login”.
Definiamo il metodo scenarios()
che restituisce un array in cui le chiavi sono i vari scenari possibili ed alle cui chiavi corrispondono come
valori degli array, a loro volta, in cui ci sono i nomi dei campi che interessano lo scenario
public function scenarios()
    {
        return [
            self::SCENARIO_LOGIN => ['username', 'password'],
            self::SCENARIO_REGISTER => ['username', 'email', 'password'],
        ];
    }
Quindi, in definitiva, una struttura buona potrebbe essere la seguente:
namespace app\models;
use yii\db\ActiveRecord;
class User extends ActiveRecord
{
    const SCENARIO_LOGIN = 'login';
    const SCENARIO_REGISTER = 'register';

    public function scenarios()
    {
        return [
            self::SCENARIO_LOGIN => ['username', 'password'],
            self::SCENARIO_REGISTER => ['username', 'email', 'password'],
        ];
    }
}
Ossia:
abbiamo creato due costanti, SCENARIO_LOGIN e SCENARIO_REGISTER, con stringhe che indicano degli
scenari (“login” e “register”). Ovviamente, non c’è una limitazione su in che modo scrivere l’algoritmo che
restituisce l’array degli scenari; si può fare in diversi modi. E’ perfettamente valido identicamente a quella
precedente, appena vista, anche questa:
<?
namespace app\models;
use yii\db\ActiveRecord;
class User extends ActiveRecord
{
    const SCENARIO_LOGIN = 'login';
    const SCENARIO_REGISTER = 'register';
    public function scenarios()
    {
        $scenarios = parent::scenarios();
        $scenarios[self::SCENARIO_LOGIN] = ['username', 'password'];
        $scenarios[self::SCENARIO_REGISTER] = ['username', 'email', 'password'];
        return $scenarios;
    }
}
?>
REGOLE DI CONVALIDA

Un modello ha un metodo di validazione dei dati inseriti/ricevuti, che controlla che i dati inseriti siano tutti
quelli richiesti e siano inseriti correttamente: il metodo validate();
Questo metodo funziona, basansosi sulle regole, che poi sono definite in un altro metodo: il metodo rules()
(regole).

Una volta che i campi sono stati caricati nel modulo si può fare una chiamata al metodo validate()

<?php
  if ($model->validate()) 
    {
        // all inputs are valid
    } 
  else 
  {
    // validation failed: $errors is an array containing error messages
    $errors = $model->errors;
  }
?>

Validate() restituisce true o false, a seconda che ritenga i campi correttamente inseriti.
Le valutazioni di validate dipendono dal metodo rules() che noi overraddiamo.
Il metodo rules definisce quali campi sono necessari e come valutare il contenuto di uno o più campi.

Per definire le regole di validazione, rules, restituisce un array multidimensionale, con una struttura ben
definita: in pratica si tratta di un array in cui in ogni cella è inserita una regola ben precisa: campi
obbligatori, regola di validazione di uno specifico campo, ecc.

REGOLA 1

REGOLA 2

REGOLA 3

REGOLA 4

Una singola regola è così strutturata: un array di 2 celle in cui in una cella c’è un altro array con l’elenco dei
nomi dei campi (quindi stringhe) e nella seconda cella c’è una stringa che indica il nome dell’algoritmo di
verifica

Campo 1

Campo 2 NOME ALGORITMO DI VERIFICA

Campo 3
Quindi possiamo immaginare così strutturato l’array delle regole

Regola1

Campo 1

Campo 2 NOME ALGORITMO DI VERIFICA

Campo 3

Regola2

Campo 1 NOME ALGORITMO DI VERIFICA

Regola3

Campo 1
NOME ALGORITMO DI VERIFICA
Campo 2

public function rules()
{
    return [
        // the name, email, subject and body attributes are required
        [['name', 'email', 'subject', 'body'], 'required'],

        // the email attribute should be a valid email address
        ['email', 'email'],
    ];
}

Qui sono restituite 2 regole, ciascuno indicato dalle rispettive celle dell’array più “esterno”;
Ogni regola è indicata da un array bidimensionale.
In queste regole, che sono 2 nell’esempio, la prima indica i campi “required”, quelli cioè obbligatori e la
seconda indica i campi che devono rispettare il formato indicato dall’algoritmo di verifica “email”.
Nel caso della prima l’array bidimensionale è composto nella prima cella da un array con le stringhe dei
nomi dei campi che sono richiesti obbligatoriamente e la seconda cella reca la stringa “required”, che indica
che i campi presenti nell’array della prima cella sono OBBLIGATORI!
La reconda regola ha solo una stringa al suo interno, che va “letta” come un array di un solo campo e tale
campo è il campo email; l’algoritmo indicato è quello che si chiama “email” ed indica che i campi indicati (il
solo campo “email” nel nostro caso) dovranno essere verificati rispettare certe regole indicate
dall’algoritmo "email”, che sostanzialmente verifica che il campo abbia un formato stringa attendibile come
e-mail.

E’ possibile, anche, indicare delle regole diverse a seconda dello scenario attivo:

<?
public function rules()
{
    return [
        // username, email and password sono obbligatori nello scenario "register"
        [['username', 'email', 'password'], 'required', 'on' => self::SCENARIO_REGISTER
],

        // username e password sono obbligatori nello scenario "login"


        [['username', 'password'], 'required', 'on' => self::SCENARIO_LOGIN],
    ];
}
?>

ASSEGNAZIONE MASSIVA

L’assegnazione massiva è una tecnica che consente di recuperare tutti i dati inviati ad una pagina e
trasmetterli direttamente a tutti i corrispettivi campi del modello – a patto che abbiano lo stesso nome –

Usando l’oggetto \Yii::$app si può accedere al suo metodo request che restituisce un oggetto contente a
sua volta altri metodi, come post(); passando al metodo post, tra parentesi, il nome del modulo da cui
derivano i dati

Quindi tramite la funzione, così scritta

\Yii::$app->request->post(‘ContactForm’);

Così,

    $model = new \app\models\ContactForm;
    $model->attributes = \Yii::$app->request->post('ContactForm');

in un solo comando,
possiamo recuperare i dati eventualmente inviati dalla view ContactForm.
In alternativa, dopo aver creato il modello con $model = new \app\models\ContactForm;Avremmo dovuto
recuperare l’oggetto dei dati inviati dal ContactForm
$data = \Yii::$app->request->post('ContactForm', []);
ed infine avremmo dovuto recuperare i dati uno ad uno, così:
$model->name = $data['name'];
$model->email = $data['email'];
$model->subject = $data['subject'];
$model->body = $data['body'];
tuttavia, se i dati non sono stati inviati correttamente (o se ne manca anche solo qualcuno) questa
operazione può dare luogo a degli errori. Quindi si dovrebbe fare una cosa tipo:

$model->name = NULL;
if (isset($data['name'])) $model->name=$data['name'];
e ripetere questo per tutti gli altri..
oppure, in maniera (comunque) più stilizzata, scrivere

$model->name = isset($data['name']) ? $data['name'] : null;


$model->email = isset($data['email']) ? $data['email'] : null;
$model->subject = isset($data['subject']) ? $data['subject'] : null;
$model->body = isset($data['body']) ? $data['body'] : null;

Che per ciascuna riga significa: se il dato inviato $data[NOMECAMPO] è settato metti nel campo $model-
>NOMECAMPO il dato inviato $data[NOMECAMPO], altrimenti mettici NULL!

In definitiva, quindi,

$model = new \app\models\ContactForm;
$data = \Yii::$app->request->post('ContactForm', []);
$model->name = isset($data['name']) ? $data['name'] : null;
$model->email = isset($data['email']) ? $data['email'] : null;
$model->subject = isset($data['subject']) ? $data['subject'] : null;
$model->body = isset($data['body']) ? $data['body'] : null;

Che, per quanto stilistico e carino è pur sempre più voluminoso ed impegnativo di

$model = new \app\models\ContactForm;
$model->attributes = \Yii::$app->request->post('ContactForm');

Il metodo di ASSEGNAZIONE MASSIVA funziona solo sui campi indicati come sicuri!
vedremo ora cosa sono e come si indicano i campi sicuri.
I campi sicuri vengono assegnati da questa tecnica, mentre quelli insicuri non vengono copiati dal comando
di assegnazione massiva \Yii::$app->request->post() , anche se sono stati inviati (e, nel caso si deve
procedere all’assegnazione manuale).
ATTRIBUTI SICURI E NON SICURI

In un modello, un attributo è sicuro se, in un certo scenario, è ritenuto OBBLIGATORIO, come negli – negli
esempi precedenti – erano username e password nello scenario “login”.

Supponiamo di avere un modello – per esempio User (come già visto prima), appunto, 2 scenari: “login” e
“register” (come negli esempi precedenti)

namespace app\models;
use yii\db\ActiveRecord;
class User extends ActiveRecord
{
    const SCENARIO_LOGIN = 'login';
    const SCENARIO_REGISTER = 'register';

    public function scenarios()
    {
        return [
            self::SCENARIO_LOGIN => ['username', 'password'],
            self::SCENARIO_REGISTER => ['username', 'email', 'password', 'indirizzo'],
        ];
    }
}
Abbiamo detto quali campi sono da considerarsi “interessati” negli scenari “login” e “register”.
Se non specificato diversamente, sono considerati sicuri.
Per indicare che un campo, ad esempio il campo indirizzo, non sia da considerarsi come sicuro, è necessario
indicarlo anteponendo un segno ! (NOT) innanzi al nome, quindi una cosa tipo:

self::SCENARIO_REGISTER => ['username', 'email', 'password', '!indirizzo']

Anche nelle regole va indicato!


Per indicare i campi obbligatori e non obbligatori, basterà indicare la lista dei campi come required
(obbligatori) anteponendo un segno ! (NOT) innanzi ai nomi di quelli non required.

Andremo a scrivere:

public function rules()
{
    return [
        [
            ['username', 'password'], 'required', 
'on' => self::SCENARIO_LOGIN ],
            ['username', 'email', 'password','!indirizzo'], 'required', 
'on' => self::SCENARIO_REGISTER ]
    ];
}
In questo modo,
nello scenario “login” (self::SCENARIO_LOGIN)
lo scenario impone che i campi “interessati” sono username e password
e
la regola impone che i campi username e password sono obbligatori

mentre

nello scenario “register” (self::SCENARIO_REGISTER)


lo scenario impone che i campi “interessati” sono username, email, password ed indirizzo ma
la regola impone che solo i campi username, email e password sono obbligatori
Riepilogando, quindi:

namespace app\models;
use yii\db\ActiveRecord;
class User extends ActiveRecord
{
    const SCENARIO_LOGIN = 'login';
    const SCENARIO_REGISTER = 'register';

    public function scenarios()
    {
        return [
            self::SCENARIO_LOGIN => ['username', 'password'],
            self::SCENARIO_REGISTER => ['username', 'email', 'password', 'indirizzo'],
        ];
    }

    public function rules()
    {
        return [
            [
                ['username', 'password'], 'required', 
                                                        'on' => self::SCENARIO_LOGIN ],
                ['username', 'email', 'password','!indirizzo'], 'required', 
                                                    'on' => self::SCENARIO_REGISTER ]
        ];
    }
}

Potrebbero piacerti anche