GlisWeb framework
Funzioni | Variabili
Riferimenti per il file _config.php

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' )
 

Descrizione dettagliata

file di base del framework

questo file costituisce la struttura portante del framework GlisWeb. Le operazioni svolte qui sono:

  1. dichiarazione delle funzioni di base
  2. dichiarazione delle costanti di base
  3. avvio dell'output buffering
  4. lettura dei file di configurazione aggiuntivi
  5. individuazione dei moduli attivi
  6. inclusione dei files di libreria
  7. inclusione dei files di configurazione

architettura del framework

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.

gestione delle chiamate HTTP

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.

organizzazione del framework

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

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

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

dichiarazione delle costanti

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.

output buffering

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

file di configurazione aggiuntivi

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

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.

moduli del framework

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.

inclusione dei files di libreria

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.

librerie esterne

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.

inclusione dei files di configurazione

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.

organizzazione dei file di configurazione

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

ordine di inclusione dei files di configurazione

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

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

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.

Da fare:

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.