symfony, creazione dati di prova (fixtures)

La preparazione dei dati di esempio per lo sviluppo ed il test di un'applicazione è sempre una operazione abbastanza noiosa che fortunatamente symfony permette di semplificare.

I dati di esempio (fixtures) sono definiti in file in formato YAML collocati in data/fixtures. Il contenuto della cartella può essere sfogliato su Google Code, qui riporterò solo un estratto di alcuni dei file con qualche breve nota di commento.

Articoli

data/fixtures/articles.yml

LyraArticle:
  art1:
    title: Un articolo su PHP
    summary: Sommario primo articolo
    content: Contenuto primo articolo
    meta_title: Meta Title di articolo su PHP
    meta_descr: Meta Description di articolo su PHP
    is_featured: true
    is_active: true
    ArticleLabels: [Php,Intermedio]
  art2:
    title: Un articolo su Mootools
    ...
    ArticleLabels: [Mootools,Elementare]

Da notare che:

• Non è necessario valorizzare le chiavi primarie dei record. Visto che sono definite in schema.yml come ID autoincrementanti, i valori vengono generati nel momento in cui il record viene inserito nel database. Quando è necessario riferirsi ad un record, ad esempio per impostare una relazione nel modo che vedremo tra poco, si utilizza un identificatore alfanumerico (in questo caso art1, art2);
• Non tutti i campi della tabella devono essere valorizzati e questo è abbastanza ovvio. Se si omette il valore di un campo sarà usato il valore di default, se definito nello schema.
• I record possono essere 'legati' utilizzando le relazioni tra tabelle definite nello schema. Ad esempio con ArticleLabels: [Php,Intermedio] nel record art1 si 'assegnano' al record le etichette Php e Intermedio (identificatori di record nella tabella Etichette come vedremo).

Commenti

data/fixtures/comments.yml

LyraComment:
  comm1:
    author_name: Pippo
    author_email: example@example.com
    author_url: http://www.example.com
    content: Articolo molto interessante
    is_active: true
    CommentArticle: art1
    ...

Penso sia interessante anche in questo caso notare come i record della tabella commenti vengono legati ai relativi articoli. Non viene valorizzato direttamente il campo article_id, visto che non conosciamo il valore delle chiavi primarie degli articoli che, come abbiamo detto, sono autogenerate; vengono invece assegnati gli identificatori dei record (art1, art2) sfruttando la relazione definita nello schema (CommentArticle).

Etichette

data/fixtures/labels.yml

LyraCatalog:
  argomento:
    name: Argomento
    is_active: true
  livello:
    name: Livello
    is_active: true

LyraLabel:
  Rarg:
    name: Argomento
    is_active: true
    LabelCatalog: argomento
    children:
      Php:
        name: PHP
        title: Articoli su PHP
        is_active: true
        LabelCatalog: argomento
      Javascript:
        name: Javascript
        title: Articoli su Javascript
        is_active: true
        LabelCatalog: argomento
        children:
          Mootools:
            name: Mootools
            title: Articoli su Mootools
            is_active: true
            LabelCatalog: argomento
          jQuery:
            name: jQuery
            title: Articoli su jQuery
            is_active: true
            LabelCatalog: argomento
  Rliv:
    name: Livello
    is_active: true
    LabelCatalog: livello
    children:
      Elementare:
        name: Elementare
        is_active: true
        LabelCatalog: livello
      Intermedio:
        name: Intermedio
        is_active: true
        LabelCatalog: livello
      Avanzato:
        name: Avanzato
        is_active: true
        LabelCatalog: livello

Come si vede ogni etichetta è legata ad un catalogo tramite la relazione LabelCatalog; esistono inoltre relazioni gerarchiche tra le etichette. Ad esempio le etichette Mootools e jQuery sono figlie di Javascript. Questo è possibile perché nello schema è stato definito un comportamento predefinito NestedSet per la classe LyraLabel.

config/doctrine/schema.yml
...
LyraLabel:
   tableName: labels
   actAs:
     ...
     NestedSet:
        hasManyRoots: true
        rootColumnName: root_id
...

Non mi dilungo in questo momento su cosa siano i nested set e rimando alla documentazione ufficiale di Doctrine: in particolare Hierarchical Data e Fixtures for Nested Sets. In futuro ci sarà forse modo di approfondire il discorso.

I dati di esempio si salvano nel database con il comando

./symfony doctrine:data-load

Arrivati a questo punto conviene eseguire anche il comando

./symfony doctrine:build-all-reload

In questo modo viene ricreata la struttura del database a partire dalle informazioni in config/doctrine/schema.yml, vengono rigenerate le classi in lib/model/doctrine e lib/form/doctrine e infine vengono ricaricati i dati di esempio. Si riceverà una richiesta di conferma perché il contenuto del database viene cancellato e rimpiazzato dai dati di esempio.

Ho eseguito il commit della revisione 7. Ecco come allinearsi alla revisione corrente per chi non abbia avuto la pazienza di riprodurre sul proprio server di sviluppo tutte le operazioni descritte negli articoli fino a questo momento. Si assume un sistema Linux con cartella progetto ~/sfprojects/lyra, LAMP e client Subversion devono essere installati e si deve aver creato un database vuoto ed un utente con i privilegi sul database come spiegato in symfony, generazione del Modello.

Da una finestra terminale digitare

cd ~/sfprojects/lyra
svn checkout -r7 http://lyra-cms.googlecode.com/svn/trunk/ .

Importante mettere il punto finale. Una volta terminato il checkout, rimanendo sempre nella cartella del progetto

gedit config/databases.yml

Modificare il file con i propri dati di connessione. Se si è utilizzato lyra come nome del proprio database e utente basta cambiare solo la password.

./symfony doctrine:build-all-reload
./symfony cc

Ora che abbiamo qualche dato di esempio nel database si possono cominciare a sviluppare le funzioni di visualizzazione nel frontend. Alla prossima.