Tyrien Framework #1

Tyrien Framework
Concepire il progetto...

1. FyleSystem - Disposizione dei file del progetto.
• /
• index.php
• loader.php
• controllers
• library
• views
  
• header.php
  
• /config/
• amodules.php - Automatic Modules
• bmodules.php - Black, Blocked, Bann Modules
• global.php - Global Settings
• path.php - I Percorsi
• wmodules.php - White Modules
• /controllers/
• /js/
• /lib/
• /log/
• /test/
• /tools/
• /views/
  
2. Il sistema - Struttura logica
   

FyleSystem - Disposizione dei file del progetto.

Dovendo questo framework essere molto versatile per il programmatore ho deciso di suddividere tutti i file in cartelle pensando che di norma un progetto, seppur di piccole dimensioni, viene spesso gestito da diversi utenti ognuno con i propri compiti.

/

"/" in ambiente *nix definisce la cartella di root ovvero la radice di tutte i file e le cartelle, l'origine di tutto. Nel nostro caso tale simbolo si riferisce alla radice del nostro progetto che nella realtà potrebbe benissimo essere /var/www/nomeprogetto/ o /home/nomeutente/www/nomeprogetto/ in base a come abbiamo configurato apache e quindi alle necessità dell'amministratore del server.
All'interno di questa locazione troviamo alcuni file essenziali per il funzionamento del framework:

• index.php
• loader.php
• header.php

Ognuno di questi file ha un suo scopo, quindi vediamo in dettaglio...

index.php

Questa pagina non è necessaria, di solito è la prima ad essere caricata e quindi gli si possono linkare direttamente i css ed i file javascript inerenti al progetto in modo tale da potersi avvalere sin da subito di una interfaccia utente funzionante, tuttavia come già detto tale pagina non è necessaria, sarebbe infatti possibile redirigere, direttamente tramite apache, l'utente su loader.php il quale si preoccuperà di inviare in risposta il client di base.

loader.php

E' la spina dorsale di tutto il sistema, consiste in un insieme di classi atte alla gestione del caricamento e gestione di tutta una serie di moduli che una volta caricati estendono le funzionalità del sistema fornendo al programmatore moltissime informazioni sull'attuale stato del sistema e della sessione dell'utente.

Il loader una volta caricato avvia una serie di script che vengono richiamati automaticamente e che possono essere specificati in /config/amodules.php.
Tra i vari moduli che attualmente possono essere caricati ci sono mysql e users, il primo altro non è che una libreria per la gestione semplificata della connessione a mysql mentre la seconda si occupa di istanziare un oggetto users contenente tutti i parametri dell'utente loggato fornendo anche tutte le funzionalità di modifica, aggiunta e cancellazione di tutti gli utenti all'interno del sistema.

Il caricamento e concatenamento di tutte queste classi avviene tramite lo script init0.

Una volta caricati i moduli automatici il loader provvede ad interpretare i dati ricevuti mediante $_POST[target] e $_POST[param] verificando che il valore di target sia uguale ad uno dei comandi interni del loader o a qualcuno dei controllers (azioni) presenti all'interno della cartella /controllers/.
Nel caso in cui il comando esista vengono caricati se presenti i seguenti file: /controllers/"$comando"Controller.php, /lib/"$comando".php e /view/"$comando"View.php.

Il valore di $_POST[param] viene preso in considerazione dal loader nel caso in cui venga richiamato un suo comando interno altrimenti viene passato al controller neocaricato.

Come visto esistono due tipologie di comandi, quelli integrati o di sistema (ping, login, logout, exit, ecc...) e quelli esterni che non sono altro che tutti i moduli presenti nel sistema.
Allo stesso tempo è possibile constatare che per ogni comando esterno ricevuto vengono caricati in tutto tre file, il controller, la libreria e la view.

controllers

Il controller definisce una singola azione all'interno del sistema derivata da un comando dell'utente o comunque da una richiesta da parte del client. Nel caso di un gioco per esempio sarebbe possibile definire il controller "Attacca" nel file "/controllers/attaccaController.php" che verrebbe richiamato ogni volta che il personaggio avrebbe voluto attaccare qualcuno o qualcosa passando tramite $_POST[param] i parametri relativi all'azione.

library

Le librerie introducono nuove funzionalità all'interno del sistema, tanto per fare qualche esempio, la libreria users istanzia un oggetto "users" contenente tutte le proprietà dell'utente loggato e fornendo diverse funzione per la gestione degli utenti in generale. Questa libreria, come pure le altre può essere caricata automaticamente all'avvio dello script oppure essere richiamata al caricamento di un determinato controller.
Questi sono i file più utilizzati di tutto il sistema, ad una libreria possono essere linkati parecchi controller.

views

Ogni controller ha a disposizione la possibilità di modificare e formattare l'output in uscita e lo fa tramite le views ovvero delle pagine in html, comprendenti javascript e css, nelle quali vengono riportati i risultati del controller con il formato <?=$variabile?> che si occuperà di introdurlo all'interno dell'html dove tramite i css potranno essere adeguatamente formattati.

Questa triplice divisione dello script favorisce il lavoro di gruppo, poiché le libreria possono essere sviluppate anche da terzi ed incluse senza sforzo all'interno del progetto, i controllers, o azioni, vengono gestiti dai programmatori del progetto corrente che plasmeranno il sistema comportamento del sistema a loro piacimento, mentre il modello della pagina verrà curato in un file apposito quasi privo di codice php e quindi più comodo per coloro che incentrano il proprio studio solo sui linguarri di marcup.

header.php

Gli header vengono inclusi singolarmente all'interno del loader includendo a loro volta tutti i file di configurazione del sistema e all'occorrenza pure lo stesso init0 sottoforma di /config/init0.php per esempio.
A prima vista può sembrare una piccolezza tuttavia tramite questo piccolo accorgimento è possibile gestire più progetti utilizzando lo stesso loader e lo stesso sistema.

I file inclusi attualmente dall'header sono:

• require_once("./config/global.php");
• require_once("./config/path.php");
• require_once("./config/amodules.php");
• require_once("./config/bmodules.php");
• require_once("./config/wmodules.php");
• #require_once("./config/init0.php");

Il contenuto di questi file verrà definito in seguito. -luca sciarratta 9/21/08 2:29 PM

/config/

Questa cartella contiene tutti i file di configurazione del sistema. Tali file possono essere riversati tutti all'interno della cartella principale oppure possono essere sistemati in sottocartelle in base alla tipologia del progetto se monoland o multiland.

• /
• config/
• nomeLand1
• configFile
• nomeLand2
• configFile
• nomeLand3
• configFile

I file di configurazione sono:

• amodules.php
• bmodules.php
• global.php
• path.php
• wmodules.php

amodules.php - Automatic Modules

$autoModules=array("mysql","user");

I moduli automatici sono quei moduli che vengono caricati all'avvio del loader ovveri tutte le volte che avverrà una richiesta da parte del client, per esempio la libreria users se utilizzata spesso o addirittura sempre all'interno di uno script può essere tranquillamente caricata automaticamente come pure la libreria mysql.
Tutte le librerie indispensabili per il sistema vengono comunque gestite attualmente in maniera monolitica l''interno del loader.

bmodules.php - Black, Blocked, Bann Modules

$blackModules=array("modulo","modulo");

I moduli inseriti nella black list sono moduli danneggiati o non stabili che si preferisce evitare di caricare, senza contare che si tenderà a creare un sistema di condivisione dei moduli particolarmente complesso che renderà l'utilizzo di questo array molto utile, ponendo il caso per esempio che i moduli da caricare non siano presi in locale sarebbe comunque possibile mantenere un qualche tipo di controllo diffidando il nostro sistema a caricare un modulo per noi guasto ed invitandolo a caricare un eventuale alternativa.

global.php - Global Settings

Qui vengono inseriti tutti i settaggi globali del progetto inerenti al core ma possono essere inserite anche configurazioni di moduli esterni anche se questo non è consigliabile.

Ecco di sotto un esempio di configurazione globale del sito, sono stati appositamente inseriti i delimitatori # INFO ZONE START e # INFO ZONE STOP per un eventuale utilizzo di sed nella modifica automatica di tale file (ovviamente in ambiente *nix).

# INFO ZONE START
const VERSION="x.x.x"; # Versione del progetto
const AUTHOR="nick_autore"; # Autore del progetto
const AUTHORLONG="nome cognome"; # Nome reale dell'autore
const PROJECT="nome_progetto"; # Nome del progetto
# INFO ZONE STOP

Tutti i valori sono costanti per renderli accessibili all'interno del progetto tramite la sintassi nomeClasse::costante, in questo caso globalSetting::VERSION o globalSetting::AUTHOR.

path.php - I Percorsi

Il file path.php contiene tutti i percorsi necessari al sistema per trovare le risorse atte al suo funzionamento. In parole povere qui vengono definite la root_path che noi fino ad ora abbiamo espresso con /, la posizione delle cartelle lib, controllers, views, config e log, che possono trovarsi anche in server differenti, ma questa feature verrà inserita ed approfondita in seguito.
Ecco un esempio del file path.php:

$root_path="";
if($root_path=="")$root_path="./";

$PATH=array(
"lib"=>$root_path."lib/",
"controllers"=>$root_path."controllers/",
"views"=>$root_path."views/",
"log"=>$root_path."log/",
"config"=>$root_path."config/"
);

wmodules.php - White Modules

$whiteModules=array("modulo","modulo");

La white list contiene tutti quei moduli che, contrariamente a quanto succede nella black list, vengono consigliato al loader. In parole povere quando il loader si troverà a dover caricare una libreria tramite questo sistema sarà possibile dirgli "se è presente questa libreria aumenta la sua priorità di caricamento altrimenti caricane una a caso tranne quelle presenti in black list".

/controllers/

Come già detto i controllers sono la parte più dinamica del sito, essi infatti prendono in esame ognuno una casistica differente, in base al comando in entrata al loader, utilizzando e combinando le librerie a disposizione per restituire il risultato voluto che poi passando attraverso la view sarà stampato come output all'interno del client.

Un esempio di struttura di un controller:

<?
class nomeController {
...
public function __costructor() {
...
}
}

$variabile=new nomeController;
?>

In questo modo il file del controller verrà incluso all'interno del corpo dello script e verrà istanziato un aggetto all'interno di "$variabile", fatto ciò partirà la funzione __costruct ovvero il costruttore, che parte in automatico ogni qual volta viene inizializzata una classe, ed eseguirà automaticamente tutto il codice contenuto al suo interno. Una volta elaborato il tutto basterà riportare nella view "$variabile" che contiene tutti i valori dati in output dal controller stesso.

Ogni controller può avere in /controllers/ una cartella con il suo stesso nome contenente file aggiuntivi per estendere il funzionamento dello stesso.

/js/

Contiene tutti i file javascript relativi all'interfaccia utente o client. Tutti i file javascript senza eccezioni devono essere messi all'interno di questa cartella, sono già presenti due librerie, raptor e scriptaculous, senza contare il file index.php che al momento rappresenta la view principale definendo il client.

/lib/

Qui sta ciò che viene realmente sviluppato secondo lo stile open, parlo delle librerie. Ogni libreria estende le possibilità del progetto introducendo nuove funzioni, estendendo quelle precedenti o modificando anche radicalmente il modo di lavorare all'interno del framework. In base alle librerie, che rappresentano il codice più riutilizzato, si può capire la qualità di un progetto pertanto verranno sviluppate direttamente dalla comunità di tyrien per tutti coloro che ne volessero sfruttare il framework di sviluppo.
Le librerie possono risiedere in locale o possono essere prese in "prestito" da qualcuno che le mette a disposizione nel proprio spazio web. Questo potrebbe avvenire perchè tramite la tecnica ajax sarebbe possibile gestire una land basata su tyrien su un dominio che non prevede l'utilizzo di php (e quindi a basso costo) facendo puntare le richieste ajax verso un sottodominio che invece offre tale servizio in modo gratuito.
Tengo a precisare comunque che è sempre meglio utilizzare questo software all'interno di un server dedicato.

/log/

Contiene tutti i file di log suddivisi in sottocartelle:

• /log/
• errors
• file di log riportanti errori
• notify
• file di log contenenti notifiche da parte del sistema
• warning
• contiene tutti gli avvenimenti pericolosi avvenuti nel sistema

Il gestore dei log è uno di quei moduli integrati in maniera monolitica all'interno del sistema, la sua rimozione potrebbe creare dei malfunzionamenti nel sistema se non si sa che codice modificare per renderli effettivi, il programmatore può servirsene a proprio piacimento facendo riferimento all'oggetto "$log".

Un esempio di utilizzo:

$log=new log;// Inizializzo il sistema dei log.
$log->write("log system READY","n");

L'inizializzazione avviene già all'avvio dello script se specificato nell'init0 tuttavia è anche possibile intercedere sul funzionamento dei log attraverso la configurazione presente nel file /config/global.php, eccone un esempio:

# LOG ZONE START
const LOG="1"; # LOG=1 (log on) LOG=0 (log off)
const FIRST_ON_START="1"; # First log write on script startup
# LOG ZONE END

/test/

Una raccolta di tutto il codice per i test sul sistema, tale raccolta verrà ovviamente pubblicata per permettere all'amministratore o al programmatore di monitorare l'andamento dello script.

/tools/

Una serie di tool per la gestione del progetto tramite comode interfacce di amministrazione o da riga di comando, più arcaica forse ma sicuramente più veloce e diretta.

/views/

Altro non sono che i modelli con cui deve essere formattato l'output all'uscita dal controller. Di solito la view principale viene mandata assieme all'index.php o dal loader.php nel momento in cui viene richiesta la prima pagina, pertanto tutte le altre view si limitano ad aggiungere codice necessario modificando l'aspetto della view principale che invece fornisce loro una buona base di funzioni ed efffetti precaricati.

La cartella /views/ contiene anche altre sottocartelle:

• /views/
• css/
• tutti i file css
• gfx/
• tutte le immagini del progetto