mercoledì 30 dicembre 2009

Lyra, personalizzare il form articoli

Ho lavorato un po' sul form per l'inserimento e modifica degli articoli in Lyra. Infatti fino ad ora la struttura del form è stata quella generata automaticamente da symfony, a parte piccole modifiche. Questo è invece il risultato del lavoro svolto (cliccare l'immagine per ingrandirla).

I campi sono organizzati in blocchi o 'pannelli' e il form si sviluppa su due colonne per sfruttare lo spazio orizzontale. Ecco a grandi linee i passi seguiti per personalizzare l'aspetto del form in questo modo.

Per prima cosa ho creato una classe form formatter come già fatto per il form commenti (vedi Personalizzare l'aspetto dei form in symfony ).

La classe sfWidgetFormSchemaFormatterLyraContent è molto semplice: la proprietà rowFormat serve a stabilire l'ordine degli elementi (etichetta, campo, messaggio di aiuto e messaggio di errore di validazione) all'interno di ogni riga del form; inoltre è stato ridefinito il metodo generateLabel() in modo da aggiungere un attributo di classe particolare (field-bool) a tutti i tag <label> relativi a campi boolean, questo per poter allineare, tramite css, l'etichetta di questi campi in modo diverso rispetto a quelle degli altri campi.

Ci si potrebbe chiedere la ragione di un form formatter per determinare l'apetto di un singolo form. Adesso il form è uno solo, quando saranno gestiti altri tipi di contenuto ognuno avrà il suo form di inserimento e modifica e tutti dovranno avere un aspetto consistente: la classe formatter ci faciliterà questo compito.

Si sono rese necessarie diverse modifiche alla classe LyraArticleForm. Invece di postare tutto il codice qui è preferibile un link al repository che mostri le differenze tra le revisioni 31 e 32 della classe.

La proprietà panels determina l'ordine dei pannelli e i campi contenuti in ciascun pannello, la proprietà break_at determina l'inizio della seconda colonna: entrambe vengono impostate nel metodo configure() e utilizzate nel template (_form.php).

Il pannello Etichette viene gestito in modo particolare. Visto che è l'utente che sceglie quali e quanti cataloghi possono essere utilizzati per categorizzare ogni tipo di contenuto, come si è visto a suo tempo, le liste di selezione delle etichette devono essere generate dinamicamente. Ho rimosso questa parte di codice dalla classe LyraArticleForm e creato un form dedicato (classe LyraLabelListsForm) che viene incluso nel form principale da queste istruzioni

lib/form/doctrine/LyraArticleForm.class.php

class LyraArticleForm extends BaseLyraArticleForm
{
...
  public function configure()
  {
...
    $label_lists_form = new LyraLabelListsForm(array(), array('ctype_id' => $ctype_id, 'selected' => $selected));
    $this->embedForm('labels', $label_lists_form);
...
  }
}

Demandare la creazione delle liste di selezione delle etichette ad una classe separata ci permetterà di evitare duplicazioni di codice quando sarà necessario gestire altri tipi di contenuto in aggiunta agli articoli. Il metodo saveLabels() è stato modificato per tenere conto di questa modifica.

Non è difficile ottenere lo stesso aspetto del form anche nel backend. L'admin generator di symfony è predisposto per suddividere i campi dei form in fieldset impostati nel file generator.yml. Per vedere come basta confrontare le differenze del file nelle revisioni 31 e 32. Non resta che modificare il template per utilizzare i fieldset come pannelli disposti su due colonne: _form.php.

Oltre a tutto questo ho aggiunto un campo ctype_id alla tabella articoli (modello LyraArticle) che viene utilizzato in schema.yml come chiave di una relazione ContentType che lega articoli e tipi di contenuto. Mi rendo conto che al momento non se ne capisce molto l'utilità in quanto tutti i record della tabella articoli hanno lo stesso tipo di contenuto ed i tipi di contenuto che saranno creati in seguito avranno proprie tabelle. Vedremo però che ci sono casi in cui tornerà comodo avere l'ID del tipo di contenuto sui singoli record.

Per il momento l'immediata conseguenza di questa modifica è la necessità per chi si allinea alla revisione 32 di eseguire dopo il checkout i comandi

./symfony doctrine:build --all --and-load
./symfony cc

La sintassi del comando doctrine:build è quella propria di symfony 1.3 e 1.4, come già detto la vecchia sintassi (doctrine:build-all-reload) è ancora valida in symfony 1.3, ma non lo sarà più dalla versione 1.4 per cui è bene abbandonarla subito.

La spiegazione delle modifiche è stata sintetica, chi abbia bisogno di qualsiasi chiarimento può lasciare un commento (finisco anche in rima). Al prossimo anno.

Nessun commento:

Posta un commento

Nota. Solo i membri di questo blog possono postare un commento.