quelques idées et propositions

Bonjour,

j'ai essayé de résumer quelques unes de mes idées aujourd'hui, notament 
vis-à-vis de la description des modules et gestionnaires et de la 
relation avec la requete interne.

j'ai placé deux XML de description sur le subversion :

http://v2.dreams4net.com:7390/svn/user/GregoireCachet/tmp/declarations/

voici un cours résumé de ce qui m'est passé par la tête :

INITIALISATION :
================

on passe au controlleur le gestionnaire a charger en premier, dans le 
module donné.
(ca fonctionne a peu près comme linux où le kernel lance 'init' juste 
apres le boot
(on peut appeler cette séquence *événement* ? voir le xml d'Eric)

Evénements : Web, Files, Reload
- Web est l'événement *normal* répondant à une requête de l'utilisateur
  On chope tout ici, sauf ce qui est des formes suivantes
    On lie dans un .htaccess via mod_rewrite à events/web.php
    Il suffira juste de récuperer $_SERVER['REQUEST_URI'] ensuite
   
- Files permet de distribuer des fichiers (css, scripts, images pour le 
design)
  Necessité de localisation à cause des images (si on veut mettre des 
titres en FIR etc)
    Proposition d'URI : /(.{2}/)(css|images|scripts)/(.*)
    On lie dans un .htaccess via mod_rewrite à events/files.php
    Il suffira juste de récuperer $_SERVER['REQUEST_URI'] ensuite
   
- Reload permet de reconstruire l'application, si on fait des 
changements dans la
  configuration, si on ajoute des modules.
    On lance donc un controlleur minimal qui peut se suffir à lui même, 
à l'aide d'un module
    particulier 'reload'
    'reload' ne doit rien utiliser en dehors des classes qui sont dans 
libs/ et qui doivent
    être indépendantes du reste
    Proposition d'URI : /reload
    On lie dans un .htaccess via mod_rewrite à events/reload.php



TYPES DANS LA REQUETE INTERNE :
===============================

Par défaut on a les types lang, year, month, day, id, file.
Dans une requete HTTP où l'on ne nomme pas les informations, on doit 
avoir un ordre strict et s'il
y a des paramètres optionnels, il faut le dire et il faut être capable 
de résoudre
- lang est le premier paramètre, doit contenir deux caractères 
numériques en minuscule [a-zA-Z]{2}, 'optional'
- year est composé de quatre chiffres et doit être une année valide 
(0000 à 9999), 'optional'
- month est composé de deux chiffres et doit être un mois valide (01 à 
12), 'optional'
- day est composé de deux chiffres et doit être un jour valide (01 à 31),
  on devra aussi valider la date par rapport à l'année et au mois, 
'optional'
- id est un identifiant, il peut contenir des caractères alphanumériques 
(majuscules, minuscule, chiffres, -, _),
  'optional'
- file permet de pointer vers un fichier attaché à une donnée. Il peut 
contenir tous les caractères autorisés
  pour un fichier sur un système de fichiers classique (voir 
restrictions). Il est 'optional' et ne peut exister
    que si id existe : 'require id'
   
S'il y a une erreur de syntaxe, on génère une erreur 404.
Dans une URI, on séparera les différents paramètres par des '/'
Ensuite, on peut ajouter des options, après le caractère '?' dans une 
URI, comme convenu précédemment.

Les modules peuvent déclarer de nouveau types de paramètres (catégories 
pour le blog). Ils devront identifier
leur position vis-à-vis des autres et les modules devront fournir une 
interface pour les identifier (à définir)
On peut avoir l'option 'multiple' pour répeter le type plusieurs fois 
(/Categorie/SousCategorie par exemple)


DOCUMENTHANDLER :
=================

Il récupère les descriptions des gestionnaires lors de la contruction de 
l'application et fabrique un arbre
qui associe à un certain type de requete un ou des gestionnaires.

-- 
Grégoire Cachet - Développeur intégrateur chez Audacy
http://www.zwiffer.org           http://www.audacy.fr
Mangeur de cigogne    http://mangeur-de-cigogne.info/