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.

http://razorblade.netsons.org/creare-un-form-con-zend-form-decorator-pattern-e-display-group-con-esempio-completo-form-di-registrazione-utente/

http://blog.spencerkellis.net/2010/06/tunneling-remote-desktop-over-ssh-in-windows-7/

In particolare tutti gli articoli in giro spiegano di usare la porta locale 3390 che viene bloccata da Windows sa il signore perché, basta usare la 3391 e buonanotte!

Ho quindi deciso di farmi in casa un benchmark che, sebbene effettuato in modo piuttosto grossolano e rapido ha dato dei risultati abbastanza netti.
Il test è stato eseguito con le seguenti condizioni (da qui capirete che è abbastanza spartano come benchmark):

• Windows 7 64 BIT
• mysql 5.1.x 64 BIT per Windows
• .NET Framework 4.0
• Utilizzato Cassini al posto di IIS
• DevArt versione 6.30.185.0
• mysql Connector NET versione 6.4.4

In pratica ho lanciato due procedure separate con la mia macchina nelle stesse condizioni di lavoro e a distanza di pochissimo tempo, quindi applicativi aperti, musica che suona e via discorrendo

Il test era suddiviso in due componenti, l’esecuzione di 1.000 query su una tabella con campo indicizzato passandogli un valore randomico e l’inserimento di 1.000 record sempre con valori randomici.
In particolare l’inserimento prevedeva il COMMIT ad ogni STATEMENT perché altrimenti non si notava alcuna differenza di performance tra i due drivers.

Di seguito i risultati nudi e crudi:

mysql (utilizzo 27%/30% CPU poi sceso in insert a 13%/15%) 6.4.4

• Data avvio select: 30/12/2011 18:12:03
• Data fine select: 30/12/2011 18:12:31
• Data avvio insert: 30/12/2011 18:12:31
• Data fine insert: 30/12/2011 18:12:43

DevArt (utilizzo 27%/31% CPU in insert a 13%/17%) 6.30.185.0

• Data avvio select: 30/12/2011 18:13:21
• Data fine select: 30/12/2011 18:13:38
• Data avvio insert: 30/12/2011 18:13:38
• Data fine insert: 30/12/2011 18:13:44

Tempo SELECT MySQL: 28 secondi
Tempo SELECT DevArt: 17 secondi

Tempo INSERT MySQL: 12 secondi
Tempo INSERT DevArt: 6 secondi

Direi che è abbastanza chiaro che, a parte una lieve differenza nell’utilizzo della CPU (in favore del driver mysql Connector NET meno esoso), la velocità di esecuzione sia delle SELECT che delle INSERT è nettamente in favore di DevArt.

Morale, bene così, almeno non ho toppato driver per un importante progetto che sto sviluppando!

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:

• www.legadelcane-carbonia.org
• www.legadelcane-porto-torres.org

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

1. Spegnete la macchina
2. Eliminate l’interfaccia di rete NAT
3. Create una nuova interfaccia legata alla VMnet8 (di solito è questa che viene identificata per la rete NAT)

• Come framework in sé non sia per niente male
• L’implementazione dell’MVC fosse buona, non eccezionale ma buona

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à:

1. Mischione logico tra View e Controller/BusinessLogic nella definizione delle form (Zend_Form)
2. Assenza di parametri nelle action
3. Action i quali nomi dei metodi devono essere tutti minuscoli, tutti attaccati e con alla fine “Action”

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.

Se vi capitasse, il problema era collegato al fatto che lo avviavo (come da sempre il 5.1 e 5.2) in compatibility mode.
Basta disattivare l’avvio in modalità compatibile e tutto funziona.
Tra l’altro ora c’è anche l’opzione per non tenerlo inutilmente nella taskbar come da standard a partire da Win 7 dello zio Bill.

Sembrerebbe dopo lunga ricerca sul web senza risultati particolari che sia un problema specifico di vmware 2.0.x con windows 7 (forse anche a 32 bit ma non ho provato).

L’unica alternativa parrebbe essere l’aggiunta di due schede di rete, una bridged (usata per navigare) e l’altra NAT per poter disporre di fatto di un indirizzo IP fisso e non dipendente dalla rete in cui ci si trova…

http://www.massimo-caselli.com mediante ZF ed MVC, la situazione che ci troviamo comunemente è composta da:

• application
• docs
• library
• public (document root di apache)

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):

• Creare il folder zend-framework sotto la document root del sito web
• All’interno del folder zend-framework installare la struttura di ZF
• Modificare il file application/config/application.ini aggiungendo la riga: resources.frontController.baseUrl = “/zend-framework”
• Proteggere il file application.ini da lettura da web (a questo punto avremo ZF all’interno della docs root del server web)
• Rimuovere pure il folder public da dentro ZF avendo prima copiato il file index.php all’interno della root del folder zend-framework
• Modificare l’ultima rewrite rule in: RewriteRule ^.*$ /zend-framework/index.php [NC,L]

Il gioco è fatto.

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).