Rilancio l’articolo di Sergio che nel suo blog spiega come creare un form con Zend Form, decorator pattern e display group con esempio completo form di registrazione utente.
Tale tecnica consente di non dover creare una view-scripts per ogni form se a priori si sa già come deve essere generato il codice html dei form.
Tempo fa mi è stato chiesto se potevo realizzare il sito web per un canile sardo, nello specifico la sezione di Carbonia della Lega Nazionale per la Difesa del Cane.
All’epoca oltre ad aver accettato ho avuto un’idea semplice ma credo funzionale, ovvero realizzare una piccola applicazioncina web che consenta la messa online di potenzialmente infiniti siti web per canili.
Ne ho quindi realizzata una prima release che si trova su Source Forge completa di codici sorgenti e di accesso SVN.
E’ ancora embrionale e sicuramente poco sviluppata, però al momento serve già con successo i seguenti due siti web:
Il progetto DogsOnWeb è in ASP.NET e si basa su MVC 2.
Chiunque volesse contribuire allo sviluppo del progetto sarà il benvenuto.
Attualmente non c’è alcun sistema di installazione, pertanto nel caso fatemi sapere e contattatemi via mail a: info@massimo-caselli.com
Dopo aver sperimentato l’utilizzo di Zend Framework in piccoli progettini, dapprima come framework puro (tipo pear per intenderci) e in un paio di occasioni con l’utilizzo della sua gestione del pattern MVC, mi ero fatto l’idea che:
Bene, sto lavorando da un paio di settimane su un progetto complesso e sto utilizzando Zend Framework nella sua piena implementazione dell’MVC.
Per cominciare (ma questo lo avevo già deciso sulla base delle precedenti esperienze), ho preferito evitare l’utilizzo di Zend_DB e della modalità che suggerisce la Zend stessa nei suoi tutorial per la gestione del model.
La motivazione era dovuta al fatto che non amavo la libreria in generale, ma soprattutto mi è sempre sembrato che la definizione del model richiedesse un overhead di sviluppo eccessivo.
Morale, il model l’ho gestito con classi scritte da me direttamente e utilizzando il caro, vecchio e affidabile adodb.
Sono però rimasto esterrefatto dalla terribile applicazione del pattern MVC per le seguenti cose, in ordine di gravità:
Vado a spiegarmi meglio, per il punto 1:
La Zend suggerisce/propina l’utilizzo di Zend Form. Le Zend form di fatto definiscono i campi del form, le validazioni e via discorrendo. Fin qui direi tutto sommato abbastanza bene, è sufficiente definire una classe ApplicationForm che estenda Zend_Form. All’interno dell’init() si aggiungono tutti i vari elementi con le loro particolarità (ovviamente alcune cose specifiche possono essere inserite sia a livello di metodi aggiuntivi della classe che direttamente da controller).
Peccato però che all’interno di questa definizione di campi, oltre a cose sensate come le validazioni, il required etc… sia necessario inserire label, id, classi css, ovvero tutti aspetti sostanzialmente relativi alla parte di view.
Infatti da controller si istanzia la classe, tipo $form = new ApplicationForm(); e $form si passa alla view direttamente. La view non farà altro che renderizzare la form.
Questo significa che se un grafico/htmlista deve modificare qualcosa NON lo può fare dalla view, ma deve chiedere (o fare direttamente) al programmatore di agire sulla classe ApplicationForm().
@Zend: ma la separazione dei livelli dove la lasciamo?
Al di là di aspetti puristici e filosofici, questo rappresenta UN PROBLEMA CONCRETO.
Punto 2:
Il minimo che potevo aspettarmi (ovviamente lo avevo già notato anche in progetti più piccoli ma davo per scontato esistesse qualche variante per gestirlo) è che i metodi delle action potessero/dovessero essere parametrici.
Invece niente, il metodo detailsAction() che vorrebbe molto probabilmente l’id da cui attingere i dati, non può essere detailsAction($id), ma $id va recuperato in get/post come si fa da 100 anni.
Ho trovato qualche variante in giro di terze parti per avere i parametri nelle action ma a parte che non funzionavano benissimo, mi pare paradossale che un framework di X Mbyte non supporti i parametri nelle action della sua versione dell’MVC.
Punto 3:
Se richiamo ad esempio: http://www.massimo-caselli.com/Article/GetArticleDetails sono costretto a nominare la action in: public function getarticledetailsAction().
E’ il minore dei mali, però insomma anche la leggebilità del codice non è che sia poi una cosa troppo secondaria.
Per farla comunque breve devo dire che in questo caso, Microsoft batte Zend nell’implementazione dell’MVC 10 a 0. 
Vediamo rapidamente come implementare Zend Framework all’interno di un subfolder.
Tipicamente i tutorial e la documentazione ufficiale parlano sempre di avere un’applicazione essenzialmente composta dalla struttura di ZF esterna alla document root, il folder public che rappresenta la document root.
Facendo un esempio pratico, normalmente per implementare il sito:
http://www.massimo-caselli.com mediante ZF ed MVC, la situazione che ci troviamo comunemente è composta da:
Ipotizzando di volere ad esempio implementare una specifica sezione del sito sotto ZF e il resto diversamente, possiamo immaginarci una soluzione di questo tipo:
http://www.massimo-caselli.com/zend-frameword
Per fare questo bastano due piccoli interventi (almeno con le versioni più recenti del framework):
Il gioco è fatto.
Se qualcuno dovesse avere come me (purtroppo per via di una lunga storia di passaggi di provider) wordpress che lavora con latin1 o meglio, ISO-8859-1 potrebbe imbattersi con alcuni temi in problemi inerenti una cattiva conversione dei caratteri in fase di renderizzazione dei commenti quando fossero presenti caratteri come “è, ì, à” etc…
Il problema nel mio caso riguardava il precedente tema Mystique (anche nell’ultima release):
http://wordpress.org/extend/themes/mystique
Non avendo né tempo né voglia di indagare ho quindi cambiato tema… (anche se un po’ mi dispiace dato che Mystique è molto bello).
.NET Massimiliano Spinetti