GlisWeb framework
|
file di base del framework Continua...
Vai al codice sorgente di questo file.
Funzioni | |
path2custom ( $p) | |
Variabili | |
const | START_TIME microtime( true ) |
const | DIRECTORY_BASE str_replace( '_src' , NULL , dirname( __FILE__ ) ) |
const | DIRECTORY_ETC '_etc/' |
const | DIRECTORY_DIZIONARI '_etc/_dictionaries/' |
const | DIRECTORY_MODULI '_mod/' |
const | DIRECTORY_SRC '_src/' |
const | DIRECTORY_CONFIGURAZIONE '_src/_config/' |
const | DIRECTORY_INCLUSIONI '_src/_inc/' |
const | DIRECTORY_CONTROLLER '_src/_inc/_controllers/' |
const | DIRECTORY_LIBRERIE '_src/_lib/' |
const | DIRECTORY_LIBRERIE_EX '_src/_lib/_external/' |
const | DIRECTORY_TEMPORANEA 'tmp/' |
const | DIRECTORY_VAR 'var/' |
const | DIRECTORY_CACHE 'var/cache/' |
const | DIRECTORY_IMMAGINI 'var/immagini/' |
const | DIRECTORY_LOG 'var/log/' |
const | DIRECTORY_LOG_LATEST 'var/log/latest/' |
const | FILE_LATEST_RUN DIRECTORY_BASE . DIRECTORY_LOG_LATEST . 'run.latest.log' |
const | FILE_LATEST_CRON DIRECTORY_BASE . DIRECTORY_LOG_LATEST . 'cron.latest.log' |
const | FILTERED_CONTROL 'FILTERED' |
const | FULL_CONTROL 'FULL' |
const | METHOD_DELETE 'DELETE' |
const | METHOD_GET 'GET' |
const | METHOD_PATCH 'PATCH' |
const | METHOD_POST 'POST' |
const | METHOD_PUT 'PUT' |
const | METHOD_REPLACE 'REPLACE' |
const | METHOD_UPDATE 'UPDATE' |
const | DB_MYSQL 'MYSQL' |
const | DB_POSTGRESQL 'PGSQL' |
const | DB_MSSQL 'MSSQL' |
const | OB_NON_ATTIVO 'NOOB' |
const | OB_ATTIVO 'OB' |
const | OB_ATTIVO_CON_GZIP 'OBGZ' |
const | SESSION_APACHE 'SESS_APACHE' |
const | SESSION_FILESYSTEM 'SESS_FS' |
const | SESSION_REDIS 'SESS_REDIS' |
const | SESSION_MEMCACHE 'SESS_MEMCACHE' |
if(ob_start( 'ob_gzhandler')) elseif(ob_start()) | else |
$cf ['mods']['active']['string'] = NULL | |
const | MODULI_ATTIVI $cf['mods']['active']['string'] |
$ct ['mods'] = &$cf['mods'] | |
$arrayLibrerieBase = glob( DIRECTORY_BASE . DIRECTORY_LIBRERIE . '_*.*.php' ) | |
$arrayLibrerieModuli = glob( DIRECTORY_BASE . DIRECTORY_MODULI . '_{' . MODULI_ATTIVI . '}/' . DIRECTORY_LIBRERIE . '_*.*.php', GLOB_BRACE ) | |
$arrayLibrerie = array_merge( $arrayLibrerieBase , $arrayLibrerieModuli ) | |
foreach ($arrayLibrerie as $libreria) | |
$arrayConfig = glob( DIRECTORY_BASE . DIRECTORY_CONFIGURAZIONE . '_*.*.php' ) | |
file di base del framework
questo file costituisce la struttura portante del framework GlisWeb. Le operazioni svolte qui sono:
Il framework GlisWeb è strutturato in una griglia formata dall'intersezione di due suddivisioni, una verticale (i moduli) e una orizzontale (i livelli); i primi rappresentano gruppi indipendenti di funzionalità e caratteristiche che possono essere attivati alla bisogna, i secondi rappresentano i passi di esecuzione del framework; l'ordine in cui il codice viene eseguito è progressivo in questa griglia partendo dal livello più basso del modulo base, per finire al livello più alto dell'ultimo modulo. Ogni livello viene eseguito per ogni modulo attivo prima di passare al successivo, e la controparte custom di ogni blocco di codice viene eseguita subito dopo alla versione standard in modo da poterne aggiustare il comportamento. Prima di questa esecuzione a griglia vengono inclusi i file di libreria con una logica di customizzazione leggermente diversa (vedi sotto). Infine l'esecuzione passa al file che ha incluso il framework, e questo segna la transizione dal framework space allo user space. Nel caso lo user space usi un motore di rendering come Twig per produrre l'output finale, l'invocazione di questo motore segna un ulteriore passaggio dallo user space all'output space.
Le chiamate alla cartella dove è installato il framework vengono smistate tramite il file .htaccess in diversi modi; il più semplice è l'accesso diretto a un file nel caso che questo esista. In secondo luogo la chiamata può essere indirizzata a una delle API del framework. Infine, la chiamata può essere rifiutata per diverse ragioni. Un esame del file .htaccess chiarirà immediatamente questi aspetti, molto più di qualsiasi spiegazione.
Il framework presenta due tipi di cartelle, facilmente distinguibili per la presenza (oppure l'assenza) del carattere underscore iniziale nel nome. Le cartelle che iniziano per underscore sono anche chiamate cartelle «standard» del framework e non dovrebbero essere modificate se non in fase di sviluppo. Ogni aspetto del framework può essere modificato, sovrascritto o esteso tramite le corrispettive cartelle locali (senza underscore), e questo è quello che dovrebbero fare gli sviluppatori che utilizzano il framework per realizzare le proprie applicazioni.
GlisWeb implementa un meccanismo molto semplice di personalizzazione, basato sui nomi dei files. Se per esempio volete modificare un valore presente in _src/_config/_010.site.php non dovete far altro che creare una copia "locale" del file, eliminando tutti gli underscore dal percorso (quindi in questo caso ad esempio src/config/010.site.php) e al suo interno dichiarare nuovamente le variabili delle quali intendete modificare il valore di default. Al momento dell'esecuzione, il framework si accorgerà dei files "locali" e li leggerà subito dopo ai corrispondenti "standard", sovrascrivendo in questo modo i valori di default.
Personalizzare il framework è quindi molto semplice; partite dai file presenti nella cartella _src/_config ed esaminate attentamente la documentazione presente in ognuno di essi, prendendo nota dei valori che dovete modificare per adattare il framework alla vostra situazione; create le necessarie copie "custom" dei file e modificate i valori che vi siete annotati; a questo punto avrete completato la personalizzazione iniziale del framework e sarete pronti per utilizzarlo al pieno delle sue potenzialità.
Le cartelle standard rappresentano la struttura del framework e vengono sovrascritte dagli aggiornamenti.
cartella | descrizione |
---|---|
_etc/ | contiene file di configurazione |
_etc/_dictionaries/ | contiene file dei dizionari per la traduzione |
_mod/ | contiene i moduli del framework |
_src/ | contiene i file sorgenti del framework |
_src/_api/ | contiene le API standard del framework |
_src/_config/ | contiene i file di configurazione del framework |
_src/_img/ | contiene le immagini standard del framework |
_src/_img/_flags/ | contiene le bandiere degli stati |
_src/_inc/ | contiene gli script inclusi del framework |
_src/_inc/_pages/ | contiene le definizioni delle pagine |
_src/_lib/ | contiene i file di libreria |
_src/_lib/_external/ | contiene i file di libreria di terze parti |
_src/_test/ | contiene i file per i test |
_src/_test/_framework/ | contiene i file per i test delle funzionalità del framework |
_usr/ | contiene files di vario tipo, che non fanno parte del codice sorgente del framework |
_usr/_database/ | contiene gli schemi e i dati di default per i database del framework |
_usr/_docs/ | contiene le pagine DOX della documentazione |
_usr/_docs/_build/ | contiene la documentazione compilata |
_usr/_docs/_etc/ | contiene i file di configurazione di Doxygen |
Le cartelle locali o custom rappresentano lo spazio in cui gli sviluppatori che utilizzano il framework per creare le proprie applicazioni possono scrivere codice che non viene sovrascritto dagli aggiornamenti.
Vediamo qui di seguito le cartelle che esistono solo in locale o che hanno in locale una valenza particolare rispetto alla loro controparte standard; la creazione delle cartelle locali necessarie al funzionamento del framework viene fatta automaticamente alla bisogna.
cartella | descrizione |
---|---|
tmp/ | cartella per i file temporanei |
var/cache/ | cartella per lo stoccaggio dei files di cache |
var/cache/twig/ | cartella per la cache della libreria Twig |
var/log/ | contiene i log del framework |
Queste costanti sono condivise e utilizzate in tutto il framewor, per questo vengono dichiarate qui; tutte le librerie e il codice del framework presuppone che esse siano presenti per il proprio funzionamento.
L'output buffering è una tecnica per cui l'output viene stoccato in un buffer per poi essere inviato tutto in una volta, eventualmente compresso, al client. Per ulteriori informazioni si veda https://www.php.net/outcontrol
Il framework supporta la configurazione tramite file JSON o YAML (vedi sotto), le informazioni contenute nei file JSON e YAML vengono lette prima delle altre e poi sovrapposte a quelle standard, di conseguenza è possibile ridefinirle tramite i file di configurazione PHP, anche se nella maggior parte dei casi questo non ha molto senso, a meno che non si desideri bloccare alcuni valori rendendoli non definibili tramite JSON o YAML.
L'array $cx ha una struttura analoga e sovrapponibile all'array $cf (vedi sotto), e viene ricavato dai file JSON o YAML di configurazione, per poi essere sovrapposto alle analoghe strutture dell'array $cf; in pratica rende possibile la configurazione del framework tramite file di configurazione JSON. Esistono due livelli di configurazione tramite JSON/YAML, il secondo pensato per la configurazione dinamica in ambiente containerizzato.
I moduli sono parti di codice opzionali che possono essere aggiunti al framework per incrementarne le funzionalità. Il framework standard comprende tutti i moduli, ma vengono considerati attivi solo quelli che hanno una corrispondente sottocartella nella cartella mods/.
I file di libreria dei moduli attivi vengono inclusi con la stessa logica standard/custom già vista per le librerie principali, mentre i file di configurazione vengono inclusi, sempre con la logica standard/custom vista sopra, solo se presenti nel modulo base.
La strategia di inclusione dei files di libreria (contenenti costanti e funzioni) è molto semplice. Per prima cosa viene generato un elenco dei files di libreria presenti nella parte standard del framework, dopodiché per ognuno di essi viene verificata l'eventuale esistenza di un corrispondente file locale. Se il file locale esiste, è incluso; diversamente, viene incluso il file standard.
Questo significa che, se si desidera riscrivere una specifica funzione del framework standard, è necessario copiare comunque l'intera libreria in locale altrimenti le altre funzioni non verrebbero trovate.
Le librerie del framework sono divise in tools e utils. Le librerie di tipo tools sono utilizzabili indipendentemente dal framework stesso, mentre le librerie di tipo utils sono legate alle logiche interne del framework (tipicamente all'array $cf) e pertanto non possono essere utilizzate indipendentemente da esso.
Il framework gestisce le librerie esterne tramite composer; le librerie vengono installate nella sottocartella _src/_lib/_external/ che sostituisce la classica cartella vendor/ di composer in modo da semplificarne la distribuzione tramite FTP.
Per l'inclusione dei files di configurazione viene utilizzata una strategia differente rispetto a quella utilizzata per le librerie; se il file locale è presente, questo viene incluso dopo il file standard.
Questo significa che se si desidera modificare il valore di una o più variabili presenti in un file di configurazione standard non è necessario copiare in locale tutte le variabili presenti in standard, ma soltanto quelle modificate. Non è ovviamente possibile ridefinire in questo modo le costanti.
La struttura dei file di configurazione costituisce l'impalcatura del framework; vengono cercati tutti i file presenti nella sottocartella _src/_config/ e nella sua controparte custom src/config/ in ordine per nome di file; per questa ragione i file di configurazione iniziano con un numero, per garantirne l'esecuzione in ordine controllato.
Il framework utilizza due array principali per archiviare la configurazione. L'array $cf contiene i dati visibili soltanto al framework, mentre l'array $ct condiene una copia di parte dell'array $cf e viene passato a eventuali template manager per la costruzione delle pagine. Questo argomento viene approfondito più avanti.
I files di configurazione del framework sono suddivisi in sezioni identificate dalla cifra delle centinaia, come si vede nella seguente tabella:
sezione | descrizione |
---|---|
000 | configurazioni iniziali del framework e del deploy corrente |
100 | configurazioni delle sorgenti dati (database, ecc.) |
200 | configurazioni relative al login agli utenti, all'utente corrente e ai permessi |
300 | configurazioni relative alle pagine del sito |
400 | configurazioni relative all'URL rewriting |
500 | configurazioni relative alla posta |
600 | integrazioni con piattaforme di terze parti |
700 | configurazioni relative all'importazione e all'esportazione dei dati |
800 | - |
900 | operazioni finali |
I file di configurazione vengono inclusi nell'ordine indicato dal nome, con precedenza ai file standard in modo da dare la possibilità ai file custom di ridefinire i valori standard, e con priorità al modulo base rispetto ai moduli aggiuntivi per dare la possibilità ai moduli aggiuntivi di ridefinire i valori base.
L'array $cf contiene la struttura dati portante del framework. Tutte le variabile importanti per l'esecuzione si trovano qui, ordinate in una struttura ad albero.
L'array $ct è un sottoinsieme dell'array $cf e ne rispecchia la struttura; contiene tutti e soli i dati che vengono passati al template manager per la rappresentazione in output; questo viene fatto per ragioni di sicurezza, per prevenire che dati sensibili vengano accidentalmente esposti in output.
finire di documentare
verificare, correggere e completare la sezione sulle cartelle
$cf['mods']['active']['string'] è un inutile doppione di MODULI_ATTIVI
$cf['mods']['active']['array'] potrebbe diventare $cf['mods']['active']
Definizione nel file _config.php.