Parliamo ora di quelle che sono le parti importanti di un CMS utile. Le caratteristiche assolutamente necessarie per un sistema di base non sono poi così tante quanto si potrebbe pensare.
Per immagazzinare informazioni di sistema importanti, design dello schermo e contenuti dello'utente, è necessario creare un database (es. MySQL). Un CMS ha bisogno di un meccanismo che consenta la di connettersi e lavorare con un database.
Un secondo elemento è rappresentato dai contenuti che si devono pubblicare dal lato web. Per scrivere articoli esistono due possibilità: pagine HTML statiche e pagine dinamiche depositate in un database. Le pagine dinamiche sono più flessibili e facili da modificare. Inoltre non solo l'amministratore e un abile co-admin possono creare queste pagine; ogni iscritto al sito può partecipare e ottenere la possibilità di inviare i propri articoli.
Un terzo elemento è dato dalla gestione delle impostazioni riguardanti la registrazione degli utenti e i settaggi dei permessi.
Ultimo, ma non meno importante, un buon CMS ha bisogno di un sistema di modelli facile da usare per poter creare pagine con un output adeguato e un perfetto design sullo schermo.
Cosa significa questo per MDPro?
La maggior parte dei CMS sul mercato (è indifferente che siano open source o commerciali) offre soluzioni complete preconfezionate che contengono una miriade di accessori, creando quindi distribuzioni di dimensioni notevoli, non facili da installare né da amministrare.
Se vogliamo offrire un CMS veramente a portata di utente è necessario essere più
flessibili, ad esempio:
Vi sono utenti che non vogliono installare i moduli che gestiscono sondaggi, recensioni, downloads e web-links. Con i sistemi attualmente presenti costoro sono obbligati ad installare tutti questi moduli prima di concellarli dall'amministrazione. E veramente necessairo questo?
In altri casi vi sono utenti che vogliono offrire un forum, una chat e una galleria di immagini. Queste caratteristiche non fanno parte del pacchetto di instasllazione. Devono quindi trovare dei moduli compatibili che si accordino ai loro bisogni. Una situazione davvero non sempre piacevole.
Detto questo, lasciatemi spiegare come si può trovare una soluzione migliore.
Per una buona funzionalità, MDPro viene rilasciato in due parti:
Un kernel che includa
un meccanismo per il database (ADODB)
Un sistema API globale per le interazioni generali del sistema (inizializzazione, DB, impostazioni, classi, variabili)
Un modulo News per editare contenuti (lato sia utente che admin)
Un modulo commenti per poter commentare le news pubblicate
Un modulo registrazione utente
Un sistema di permessi (admin, utenti e gruppi)
Strumenti di amministrazione per le ipostazioni generali del sistema
Un meccanismo di creazione temi (Autotheme, Encompass, ecc.) o un tema leggero per un output uniforme
Un punto centralizzato di raccolta per icone, smilies, pulsanti, scripts, funzioni
Addons
Maggiori accessori o caratteristiche codificate come moduli separati, blocchi o librerie
un maggior numero di temi complessi (skins)
Pacchetti per le le altre lingue (l'inglese fa parte del kernel ed è base per tutte le altre lingue)
API caricate temporaneamente per determinati moduli
una "collezione" di API aggiuntive per funzioni varie ("scatole nere" come uno strumento di selezione di colori, uno strumento per scegliere le date, ecc.)
per offire il nostro MDPro a differenti gruppi di utenti secondo le loro esigenze, si possono creare diverse distribuzioni. Tutte queste distribuzioni includeranno il kernel più una selezione di addons.
Cosa questo significhi lo spiegherò nel prossimo capitolo.
Come avete pototuo leggere sopra, dobbiamo cambiare il nostro modo di pensare. Dobbiamo suddividere il pacchetto attuale di MDPro in diverse parti. Ma lo sviluppo nel suo complesso sarà più visibile e meglio organizzato.
Inoltre, una maggior pulizia del codice aiuta lo sviluppo di base perché il kernel è piccolo e si adegua perfettamente solo a quelle parti che sono assolutamente necessarie per un sistema funzionale. la maggior parte di tutti i problemi e bug possono essere trovati e risolti nel kernel. Lo sviluppo di base può concentrare le proprie attività e non ha bisogno di pensare a cosa accadrebbe con il modulo tale o il blocco talaltro se si cambia il codice.
Dopo aver definito cosa sia un kernel e cosa sono gli addons ogni sviluppatore può trovare il proprio posto all'interno dell'intero progetto, dove può dare il suo contributo migliore.
Gli sviluppatori di moduli possono usare il kernel come una "cassetta degli atrezzi". Possono prendere tutte le API che servono per i loro moduli. Possono codificare i moduli con un aspetto omgoeneo alle altre parti di MDPro. Quantomeno non hanno bisogno di codificare di nuovo alcune funzioni perché possono trovarle già pronte nelle API.
Se suddividiamo MDPro, sarà più facile cambiare o modificare alcune parti delle distribuzioni perché queste parti sono codificate come moduli separati e non faranno crescere il kernel (ad es. la mia idea del modulo news che è al 100% compatibile API e rimpiazza il vecchio modulo "Invia_News", "AddStory" e Commenti è separata come modulo che usa hooks (lett. agganci), molto flessibile).
Un'altra serie di buone ragioni è data dalla documentazione e dallo sviluppo del tema.
Documentazione
Il kernel non include troppe caratteristiche e i cambiamenti o le modifiche non sono così complicati. Riguardo a questo si può creare una documentazione utente di base senza cambiarla ad ogni nuovo rilascio di distribuzione. Gli estensori del documento possono concentrarsi sulla scrittura di documenti aggiuntivi per le distribuzioni e aiutare i traduttori che devono scrivere poi la documentazione in altra lingua.
Un altro aspetto riguarda il sistema di aiuto online e i manuali per gli utenti e l'amminsitratore.
Non vanno poi dimenticate le linee guida per gli sviluppatori. Senza un buon documento su come si sviluppa nessuno saprebbe cosa fa parte di un kernel e cosa no.
Temi [skins, modelli]
Parliamo di temi e intendiamo ciò che appare sullo schermo, il modo in cui vogliamo presentare l'output lato client. Preferisco usare in futuro "skins" o "modelli" e non "temi". Perché abbiamo bisogno di questa espressione anche in connessione con i contenuti, le news e gli articoli.
Autotheme è parte di MDPro così come Smarty (Encompass) è parte di Envolution e Postnuke. Il motore di Autotheme è quindi parte del kernel. Come opzione è possibile installare Encompass come modulo. Questo comporta per coloro che disegnano i layout per lo schermo il massimo della flessibilità per creare modelli nuovi e professionali per e con MDPro. Per la versione del kernel di MDPro dobbiamo creare uno skin molto leggero senza alcuna caratteristica quale Javascripts, applets, immagini e strutture complesse.
Il linguaggio di supporto deve essere l'inglese. E' di grande importanza che questo pacchetto linguistico sia completo al 100% e privo di errori.
Anche questo pacchetto di lingua inglese è parte del kernel e fonte di tutte le altre traduzioni.
Nota:
So bene che non è così semplice come sembra dividere e ristrutturare una versione base di MDPro. Vi sono troppe ragioni storiche che infrangono le regole. Ma uno dei nostri primi compiti è ripulire il codice. Ora è il momento migliore per farlo.