Ci sono delle cose che si apprendono solamente con il tempo ed errori che tutti facciamo nell’esplorare un nuovo tool. Ecco un’elenco di “errori da principiante”.

Debug abilitato in produzione

Un errore comune, le performance della nostra applicazione saranno pessime. Lasciando il debug attivo mettiamo inoltre a rischio informazioni e dati che abbiamo utilizzato nella fase di sviluppo. Per disabilitare il debug impostiamo il valore a 0 nel file /app/Config/core.php e cerchiamo la riga Configure::write(‘debug’, 1). Il valore di debug può essere 0, 1 o 2.

Impostazione errata del recursive

CakePHP di default ha impostato il recursive a 1. Questo valore prenderà tutti i dati dei modelli associati con HasMany e BelongsTo, rendendo la nostra applicazione pesante. Ritengo che questo livello sia esageratamente elevato. Possiamo migliorare la situazione: disabilitiamo per tutti i modelli il recursive. Impostiamo in AppModel la proprietà $recusive = -1;

Non Utilizzare Containable

Lo step successivo al precedente è l’utilizzo del Behavior Containable. L’utilizzo del recursive a -1 e l’abilitazione del containable è la maniera per assicurarci delle performance migliori. Personalmente abilito il Behavior in AppModel perché lo utilizzo ovunque ma, se lo gradite o non potete utilizzarlo ovunque, è possibile abilitarlo nei singoli modelli. Documentazione Ufficiale

Selezionare tutti i campi dei modelli

Cerchiamo di non selezionare tutti i campi dei modelli, limitiamoci a quelli necessari alle nostre operazioni.

Business Logic nel Controller

Questo è l’errore più comune. Si tende a lavorare principalmente nel controller ignorando così i principi di DRY (Don’t Repeat Yourself, ovvero: Non Ripeterti) ed andando ad appesantire il controller di un lavoro fatto per il modello. Spostiamo tutti i vari find nel modello, inizialmente ci sembrerà inutile ma, nel periodo medio lungo, troveremo questa pratica molto utile. Ricordate, Fat Models e Skin Controllers, come da motto di CakePHP.

Non utilizzare i Behaviors o Components

Non sono nulla di strano! In questi oggetti inseriremo il codice condiviso dai Modelli (Behaviors) o dai Controller (Components) così da rispecchiare il concetto di DRY.

Non ottimizzare le Routes

Come spiegato nel primo articolo dedicato alle Routes di CakePHP le routes vengono lette dall’alto in basso. Spostiamo, dove possibile, le risorse con più accessi in alto.

Non controllare gli aggiornamenti del Core

Spesso vengono risolti degli errori critici o implementate nuove funzionalità che possono migliorare molto la nostra applicazione (come il log rotation). Controllate i changelogs qui

Non leggere la documentazione

Presi dalla magia del framework crediamo di poter risolvere tutto “smanettando”. Purtroppo non è così. Nel lavoro giornaliero ho sempre una scheda aperta sul cookbook ed una sull’API. Fate altrettanto, è una risorsa fondamentale.

Ignorare PHP.net

L’euforia da framework fa dimenticare il bagaglio che abbiamo acquisito durante gli anni. Ricordate, CakePHP è un framework PHP!

Non leggere i log

Nelle fasi pre-produzione è sempre tutto fantastico ma, una volta andati online, potremmo non aver previsto delle situazioni che l’utente riesce a generare. Non ignoriamo i file di log, li trovi sotto /app/tmp/logs/.

Non seguire gli standard

“Convention Over Configuration”  è il motto principale di CakePHP, ignorare (o seguire solo in parte) le convenzioni non può che danneggiare il nostro lavoro nel medio/lungo termine. Qui la documentazione ufficiale.

Conclusioni

Chiudo questa lista con la speranza di aver lasciato delle informazioni utili ed aver accesso la vostra curiosità. Vi ricordo che potete sempre trovare aiuto nel nostro gruppo su Facebook.

Seguimi

Latest posts by Walter Raponi (see all)

Articoli Correlati:

Le Relazioni CakePHP – HasMany (uno a molti) Le Relazioni CakePHP – HasMany (uno a molti) seconda parte Integrare WordPress con CakePHP Route Elements, URL dinamici in CakePHPRoute Elements, URL dinamici in CakePHP