Linee guida per un CMS casalingo: il progetto
Lunedì 28 Gennaio 2008 - 09:01
di Claudio Garau
Se non volete utilizzare soluzioni già pronte per il content managing e siete attirati dalla sfida di creare un vostro CMS, può essere utile avere a portata di mano una serie di regole in grado di facilitare il lavoro di sviluppo.
Le linee guida di cui parlerò si basano sulla mia esperienza lavorativa, per questo motivo non sono di certo né vincolanti né inopinabili; sono semplicemente dei consigli che spero possano tornare utili.
Dato che il discorso non è breve, lo distribuirò in più post dedicati ai diversi aspetti dello sviluppo.
Questa volta parleremo dei presupposti di base che elencherò, premettendo da subito, che sicuramente qualche punto verrà dimenticato, i contributi nei commenti possono essere quindi preziosi per integrare l’argomento con utili risorse.
Detto questo, credo che dei buoni presupposti per la creazione di un CMS casalingo siano riassumibili nelle seguenti voci:
- l’applicazione deve essere realizzata in un linguaggio ben supportato: in questo caso credo che PHP sia la soluzione ideale: permette di contare su un manuale di riferimento che pochi altri linguaggi mettono a disposizione, è semplice trovare aiuto in caso di problemi, non è difficile reperire dell’hosting adeguato. ASP lentamente scompare, Ruby on Rails non è ancora abbastanza diffuso, Java è complesso quindi la scelta è quasi obbligata;
- l’applicazione deve essere riutilizzabile: quello che vogliamo creare è un CMS, deve essere in grado di gestire contenuti indipendentemente dalla loro tipologia e dall’argomento trattato; è necessario quindi che sia dotata di un buon sistema di gestione delle categorie e delle sottocategorie, che integri un editor visuale personalizzabile con supporto per la gestione dei file, che consenta l’amministrazione anche ad un utente non sviluppatore e che possa essere facilmente integrata nei template;
- l’applicazione deve separare il codice dinamico dal markup HTML: torniamo quindi al discorso della riutilizzabilità. Meglio pensare subito ad una soluzione basata su un template engine collaudato e supportato, Smarty può essere un buon esempio.
- l’applicazione deve essere in grado di generare pagine già ottimizzate: deve essere possibile gestire nel modo migliore i metatag ma anche elementi non secondari per il SEO come gli attributi dei link e le URL. Meglio pensare subito ad una struttuta delle querystring che consenta la riscrittura;
- l’applicazione deve interfacciarsi ad un database: utilizzare un flat file come strumento di memorizzazione può essere comodo, ma pone dei limiti dovuti alla mancanza di una struttura di relazione tra i contenuti. MySQL non è necessariamente la soluzione migliore, ma è sicuramente una delle più diffuse e supportate.
Questo per quanto riguarda il progetto iniziale, al momento non abbiamo ancora scritto una sola riga di codice, ma presto passeremo all’azione.
Commenti
1
Interessante, l’unica mia perplessità rimane smarty:
lo sto usando per un progetto e mi ci sono trovato male, perchè ho dovuto imparare tutta una serie di cosette che mi hanno complicato le cose invece che rendermele più semplici.
Non credo sia un cattivo compromesso tenere dei file template con delle piccole iniezioni di semplice PHP piuttosto che usare sintassi diverse.
Tu ti trovi bene con Smarty?
# - postato da JoomlaShow - 28 Gennaio 2008 - 11:42
2
non sono d’accordo sulla questione del linguaggio da utilizzare.
ASP è vero che sta scomparendo.. ma non perchè si sta lentamente sostituendo con la sua evoluzione .NET : Asp.Net.PHP nella versione 5 non è così semplice come era il 4, in quanto è ormai diventato un linguaggio con paradigma ad oggetti vero e proprio, al contrario del 4, che era un pò un ibrido tra un linguaggio di scripting strutturale ed uno ad oggetti.
Java e .NET sono complessi fino a che non li si conosce :) .. Ci sono cose che in Java e .NET le si fa in 3 linee di codice, e per farle in PHP ci vogliono 20-30 linee.
La separazione del codice: se usi Asp.Net, già nativamente sei obbligato a seprare la presentazione, con il codice, già proprio in file diversi! mentre in PHP o similari devi farlo a mano, utilizzando librerie di terze parti come Smarty.
Quindi in sintesi, secondo me è sbagliato dire a priori “dovete utilizzare PHP perchè è facile”.
Non è così… dipende da quello che si deve fare, ogni linguaggio si adatatta meglio a certe cose, meno ad altre. E dipende anche da che conoscenze si hanno di un linguaggio e di un altro… :)
3
Per JoomlaShow:
Concordo sul fatto che Smarty per essere usato al meglio necessita di una conoscenza molto approfondita, diversamente può risultare addirittura un problema in più con cui fare i conti.
Ma è sempre meglio utilizzare un template engine che passar ore a spiegare al grafico cosa deve toccare e cosa no.. :-)Per Davide:
tieni conto però che la mia idea è quella di creare un’applicazione più semplice possibile; deve essere facile trovare un hosting (anche di fascia economica), deve essere facile reperire aiuto, deve essere semplice da installare etc.
PHP non è necessariamente la soluzione migliore, ma è sicuramente la più supportata e diffusa.# - postato da Claudio Garau - 28 Gennaio 2008 - 15:17
4
Il mio CMS usa anche la tecnologia Smarty, e devo dire meno male che c’é!
Così si separa la grafica dalla logica di programmazione.
Il programmatore mette mano ai file in php, mentre il grafico modifica i tpl.Personalmente consiglio questa soluzione.
5
Io sono d’accordo con l’idea che ogni cosa si adatta ad uno scopo. Ci sono casi in cui per piccole aziende o per professionisti un DB può non essere necessario. ! I vantaggi sono molti: hosting meno caro, basta un server meno prestante, e soprattutto il sito può essere preso e spostato come una cartella. Inoltre puoi creare un applicativo lato client (intendo proprio un EXE) per gestire il sito offline e caricare le modifiche alla fine, sfruttando un motore php residente sul server che scrive i files in locale, il che consente anche facili backup del sito. Poi per moltissime altre cose è un sistema improponibile, ma per me non da eliminare.