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.

1. 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.
2. 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.
3. Un terzo elemento è dato dalla gestione delle impostazioni riguardanti la registrazione degli utenti e i settaggi dei permessi.
4. 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:

1. 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
2. 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.

1. 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.
2. 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.  

Dopo aver definito il nostro kernel possiamo creare la nostra distribuzione principale. Come ho detto nel capitolo 3 una distribuzione include:

1. Il kernel
2. Acluni addons
3. uno skin di  Autotheme bello e potente

La definizione per la nostra distribuzione principale si chiajma "MDPro [versione no.]". Questo pacchetto comprende la maggior parte delle funzionalità conosciute dalle precedenti versioni di altri progetti come  Envolution e PN. Ma ricordate cosa ho detto prima: questa distribuzione include più di un pacchetto.

Come si può fare?
Prima di tutto l'utente deve scaricare e installare il pacchetto base. Questo pacchetto comprende una routine di installazione completa. Il programma di installazione dà all'utente la possibilità di selezionare i moduli che vuole installare, quali impostazioni ha bisogno per il suo sito e quali contenuti principali vuole pubblicare. E' una procedura passo passo come quella attuale, ma più  flessibile.
Per ogni addon selezionato l'utente deve considere qualche dettaglio in più:

• "prima dell'installazione"
• "durante l'installazione"
• "dopo l'installazione"
• dettagli del pacchetto (come RPM per Redhat-Linux)

Come ognuno sa, è impossibile includere tutti i moduli desiderati e le migliorie in un solo pacchetto. Vi sono troppi sviluppatori in giro per il mondo. Ma il kernel di MDPro è molto flessibile e l'utente può selezionare e utilizzare molti di questi  moduli (quasi il 98%) codificati per  PN, Envolution e/o MDPro.
Quando pensiamo a tutti i professionisti che vogliono usare MDPro, possiamo predefinire alcuni pacchetti per rendere loro più facile avere i migliori addons compatibili al 100% con MDPro.

Dal punto di vista degli sviluppatori si può agire in questo modo:

• Trovare moduli per i compiti necessari senza cambiare nulla (es. argomenti).
• Trovare moduli e codificare piccole modifiche per renderli compatibili al 100%  (es. Arena forum).
• Trovare programmi e codificare dei collegamenti per includerli in MDPro (es. phprojekt).
• Ricodificare completamente i moduli

Un'altra possiblità  è quella di includere programmi esterni, ad esempio PostWrap. Ma questa non è una soluzione di sviluppo, è solo un aggirare il problema.


Tutti i moduli trovati e ritenuti utili valide estenioni di  MDPro avranno lo status "certificato per MDPro". Questo garantisce che lavorino in maniera corretta e che sono supportati dal team Maxdev  (o dallo sviluppatore originale che lo ha sviluppato per MDPro, too).
Per rendere le cose più semplici possiamo incorporare alcuni moduli per vari pacchetti di distribuzione come:

1. mdCommerce (sistema di shopping)
2. mdGroupware (phprojekt + Mantis)
3. mdLearning (spaghetti, claroline, moodle, mimerdesk, etc.)
4. mdCommunity (mailinglists, chat, forum, etc.)
5. mdWebadmin (ServerTools, advStats, etc.)
6. Misc (Sondaggi, FormCreator, Punteggi, etc.)

Si possono trovare più prodotti per una distribuzione (es. Arena Forum, pnPHPBB2). Meglio sarebbe tuttavia basarsi su uno solo (il migliore.

Lo stesso dobbiamo fare con i blocchi (che non sono parti di un modulo), scripts (es. Javascript menu), applets e altre funzioni non direttamente parte del CMS.

Tuttavia dobbiamo considerare anche le parti esterne, la parti terze e gli scripts che non toccano il kernel. MDPro deve funzionare correttamente con o senza queste distrubuzioni ed estensioni.
Ancora, deve essere possibile sostituire un addon con un altro migliore (es. cambiare  dal modulo forum Arena al modulo forum phpBB2).

Per implementare parte o tutto il pacchetto di distribuzione, dobbiamo codificare una piccola routine di installazione. Questo può essere fatto sia come versione singola sia come parte di una procedura di installazione generale.