La struttura e' invece contenuta in blocks/structure.inc che provvede al caricamento dei blocchi e delle applicazioni. È comunque possibile inserirla nel tema corrente nel caso in cui servano personalizzazioni molto elevate nell'impaginazione che non è (ancora) possibile ottenere con i fogli di stile.

E' quindi possibile cambiare la forma del sito senza cambiare il tema e viceversa. Anche, al limite, l'assenza di un tema non interrompe la disponibilità delle informazioni.

Per questo si puo dire che i temi di FrameWork sono a struttura non portante;

Le sotto pagine centrali sono dette applications (quelle che altrove sono section o modules per intenderci) ed il menu che le lancia e' un blocco come gli altri.

I blocchi hanno 4 cartelle per collocarli top,left,right,bottom.

Il titolo e il footer sono blocchi, osa che solitamente non e' nei pacchetti simili.

Blocchi e Applications possono essere indifferemntemente cartelle o semplici file.

I dati la grafica e la localizzazione devono accompagnare il blocco o l'applicazione quindi se sono necessari verranno ospitati nella cartella del blocco/applicazione. Per convenzione si porranno in essere due cartelle proprio a questo scopo denominate: images e lang.

Questa soluzione rende molto piu facile l'aggiunta e la rimozione dei componenti (siano essi blocchi applicazioni librerie o altro) grazie alla loro compattezza intrinseca.

Per nascondere un componente e' sufficente far precedere il nome dal carattere sottolineato (_).

I dati invece vengono conservati nella cartella datas che viene generata se non presente automaticamente al primo avvio.

Tutti i dati delle applicazioni, dei blocchi e delle librerie devono essere registrati in questa cartella in sotto cartelle che devono riprodurre in qualche modo la struttura del sito stesso

Per il sort si usa il collaudato sistema del numero che precede il nome seguito da un _.

Ovviamente non e' possibile usare spazi nel nome applicazione/blocco.

In questo caso Il numero non viene usato nel generare la cartella in datas e ovviamente la creazione della cartella dati e' a carico del blocco o del'applicazione usando pero’ funzioni fornite dalle librerie standard.

Blocchi e applicazioni hanno anche in carico la creazione della propria cornice e della propria amministrazione.

In pratica FrameWork passa la parola al blocco/applicazione e mette a disposizione le proprie funzioni.

Sara' poi quest'ultima a svolgere il resto del lavoro avvalendosi del codice a disposizione nelle librerie.

La directory datas contiene l’unico posto dove framework puo’ scrivere e conservare informazioni. I dati sono organizzati in cartelle che rispecchiano la struttura delle directory adoperate per le applicazioni (per esempio: i dati di forum sono conservati in datas/applications/forum). La creazione delle cartelle necessarie è demandata ai blocchi e/o applicazioni che ne fanno uso.

I dati riservati vanno nella security box (sb) che usa una sotto cartella generata automaticamente da un’apposita funzione che ha il compito di nascondere l’accesso ai dati da remoto.

Un esempio di una cartella generata in automatico e’:

La configurazione generale (lingua, ora, path, ecc.) viene impostata attraverso la libreria libConfig.inc.

I dati di impostazione sono generati da un apposita routine e sono conservati in datas/config.

Una specifica applicazione di amministrazione permette poi di personalizzare questi dati.

Questa struttura assomiglia in qualche modo il registro di windows pur essendo infinitamente piu semplice. E' la miglior soluzione che abbiamo trovato per centralizzare la configurazione in un sistema modulare espandibile a piacere.

Da notare che la lettura / scrittura della configurazione è eseguita da funzioni e non con variabili.

Esistono poi alcune funzioni che restituiscono con semplicita dati globali. Queste funzioni sono conservate nella libreria libConfig.inc
Questo approccio consente di avere la restituzione di dati in maniera piu intelligente.

Faccio un esempio:

la funzione lang() restituisce la lingua impostata pero' e' in grado di verificare (ipoteticamente) la presenza del cookie lang.

E' in grado anche di rimediare la lingua dai dati del server e infine se proprio non e' possibile capire la lingua dell'ospite usera il valore di default stoccato in datas/config.....bello vero?.

Ovviamente tutto questo e' configurabile e non incide sul funzionamento del resto della struttura.

Basta mantenere i nomi delle funzioni invariati.

E' anche possibile aggiungere nuove funzioni.

L'amministrazione fa parte del core tuttavia e' implementata esternamente ed e' possibile sostituire o scrivere versioni alternative senza intaccare il buon funzionamento di FrameWork.

Le funzioni dell'amministrazione sono  locate nella libreria libAdmin.inc e c'e' a disposizione il blocco admin per l'inserimento password.

E' stato poi creata l'applicazione admin per la configurazione delle preferenze dell'amministratore oltre che altrnativa al blocco di autenticazione.Questa applicazione ma anche molte altre e' un container. Si tratta cioe' di un contenitore di altre applicazioni. Questo approccio semplifica e modularizza ulteriormente il sistema dividendo le varie funzionalita' in tante piccole sotto applicazioni.

L'amministrazione non usa un utente particolare (anzi non usa proprio nessun utente) e usa sia un cookie (disattivabile) che un autenticazione mediante indirizzo ip. Solo un utente per volta puo' amministrare il sito e per poter amministrare deve prima di tutto avviare la propria sessione immetendo la password attraverso l'apposito blocco.

A questo punto il sistema registra l'ip dell'amministratore, posta l'eventuale cookie e non richiede piu' la password.

Riconosce inoltre l'amministratore ed espone i servizi di amministrazione che altrimenti non sono accessibili.

Quando l'amministratore ha terminato il lavoro è tenuto a scollegarsi usando il comando stopsession.

Questo tipo di autenticazione mi sembra piu' sicura di una generica basata solo su cookie.

E' possibile comunque implementarne una basata su meccanismi differenti semplicemente sostituendo la libreria libAdmin.

Il text editor interno e' un accessorio dell'amministrazione ma come logico in questo sistema non ne fa parte ma e' un applicazione come le altre.

Si tratta di un applicazione nascosta e non puo' funzionare da sola poiche necessita che le venga passato il nome del file da editare.

Puo' anche funzionare senza i privilegi di amministrazione ed essere usato da applicazioni normali in quanto svolge solo i compiti di editazione e non il salvataggio.

E' evidente che questa parte e' cruciale per la sicurezza.

In frameWork l'editor puo' caricare il file e modificarlo ma per il salvataggio si aspetta che l'applicazione che ha richiesto il suo intervento sia in grado di ricevere le modifiche e sia in grado di salvarle.

Ogni suggerimento di sicurezza in questa parte e' il benvenuto e anche
un testing forzato e sistematico deve essere svolto con cura per prevenire possibili bugs.

_editor.inc funziona sia da solo sia con il supporto presente nella cartella extras di FCKeditor che nel caso fosse presente sara' automaticamente usato.

In generale, le librerie sono invece presenti in una cartella chiamata libs e vengono caricate automaticamente come i blocchi.

Qui’ e’ stato fatto un ulteriore passo avanti e solo le librerie che nel nome hanno come inizo al_ vengono caricate automaticamente, le altre devono essere invocate dalla funzione loadlib che verifichera' che la libreria non risulti gia caricata.

Fw puo' essere installato nel modo convenzionale scompattando un archivio zip ma puo' anche essere installato direttamente sul proprio spazio web attraverso una connessione ftp usando un browser.

E' possibile ottenere un archivio zip ricavato in tempo reale dall'installazione del sito stesso. in questo caso però è chiaro che i dati conservati in datas non vengono inclusi nell'archivio stesso.

E' infine possibile tramite un altro tool decidere cosa includere nel proprio archivio zip o se si preferisce cosa installare via ftp nel sito stesso direttamente.

Possiamo dire che l'installazione del sistema framework e' sicuramente molto semplice. Al primo avvio tutti i dati saranno configurati ai valori di default e poi l'amministratore proveddera' a personalizzarsi il sistema. Non è previsto alcun wizard di prima installazione ma non escludiamo a priori che in futuro possa essere implementato.

Il sistema FrameWork può essere aggiornato in modo automatico senza bisogno di visitare il sito principale.

Il sistema (unico per quello che ne sappiamo) di fatto ha cancellato il concetto di versione e permette di fissare bachi e/o aggiungere funzionalita molto in fretta e in modo automatico e indolore. In futuro sara' possibile installare nuove parti e potrebbe anche incorporare una struttura per rendere disponibili con facilita’ nuove applicazioni/blocchi o parti modificate da altri utenti. Rendere semplice ed efficente la pratica di queste operazioni è la sfida che aspetta il team nei prossimi mesi.

Il meccanismo fa leva sul fatto che l'estensione della maggior parte dei file di FW è .inc e quindi se richiesti al server HTTP direttamente questi vengono spediti senza essere elaborati dal parser PHP e quindi in forma sorgente. I problemi sorti sono stati in gran parte risolti. Restano da dettaglizzare alcuni comportamenti particolari e deve essere ancora implementato un meccanismo di risoluzione delle dipendenze.

Il meccanismo ideato consente anche di avere fonti distribuite su piu siti e indirettamente apre agli utenti la possibilita di condividere/aggiornare i propri moduli e le proprie applicazioni direttamente e in modo indipendente dal server principale. Al momento un applicazione dell'amministrazione si fa carico di questa operazione.

Il punto di arrivo è un applicazione simile al tool debian synaptic che consenta di avere gli aggiornamenti, l'installazione e la disinstallazione dei pacchetti che compongono framework in modo del tutto automatizzato e semplificato al massimo.

Il codice presente è stato ideato solo come codice esplorativo per verificare la effettiva fattibilita' di questa idea.

Tuttavia, a 18 mesi dall'inizio dello sviluppo riteniamo che questa implementazione possa essere usata con ragionevole sicurezza per siti dal basso medio carico.

Ringraziamo naturalmente tutti coloro che hanno contribuito a questo esperimento e siamo naturalmete a disposizione tramite mail per ogni ulteriore chiarimento.