Re: Mise au clair personnelle

Le Samedi 3 Avril 2004 18:58, Gregoire Cachet a écrit :
> a mon avis, faut découper (j'utilise ta dénomination module) :
>
> - un module pour parser l'URI
> - un module pour l'interpreter
> - un module pour savoir ce qu'il faut récuperer comme documents
> - un module pour faire les transformations
> - etc ...

Vu qu'un module dispose de ses propres classes et peut définir plusieurs 
évÚnements dans son contrÎleur, je pensais à regrouper l'ensemble des 
fonctionalités de base dans un seul module. Ce n'est pas absurde et ça évite 
de créer X modules dépendants les uns des autres pour des fonctionalités 
analogues.

Mais ton idée n'est pas mauvaise et aprÚs réfléxion, on pourrait peut-être 
trouver bon un compromis : j'ai pensé à intégrer UriParser dans les 
librairies standard, et à définir un nouveau type d'évÚnement de ce type :

$ctrl->setUriEvent($uri_pattern, $handler);
"si l'uri satisfait le masque $uri_pattern alors lance le gestionnaire 
$handler"

En pratique on pourrait définir ça dans le contrÎleur du core

$ctrl->setUriEvent('*', $uri_interpreter);

Donc l'uri est envoyée à la classe UriInterpreter du core pour interprétation. 
Si au bout du compte l'uri n'a pas été interprétée (la categorie X n'existe 
pas ou assimilé) les autres modules pourraient surcharger l'évenement par

$ctrl->setUriEvent('^/Stats', $stats_manager);

(bien sur ce n'est pas tellement conseillé mais c'est une possibilité) et 
l'interpréter à leurs façon. Je sais pas si j'ai été assez clair ...

> Pour ce qui est de l'admin, je pense que ca ne doit pas être un module
> particulier, simplement une requete interne ... Pourquoi gerer
> l'administration sur un autre niveau ?

Parceque pour moi, en dehors de toute définition de module, l'appli ne fait 
que gérer bêtement des données sans signification, exécuter des évennements, 
etc. Comme j'ai dit c'est presque un framework (bon sans que ça le devienne, 
ce n'est pas véritablement le but ;-) ) : on peut lui faire faire 
pratiquement ce que l'on veut et ça, ça va être chouette :-)

C'est pour ça qu'intégrer l'admin dans l'appli de base ne me parait pas une 
bonne idée. De plus l'admin n'est qu'une surcouche graphique à la 
manipuiation des données : on peut modifier la conf à la main, définir 
l'erreur http à la main, ajouter un article à la main ...

Mais attention, lorsque je parle de module d'admin, je ne parle pas d'un 
module d'admin qui administre tout par lui même, je parle d'un module d'admin 
qui gÚre l'administration _par rapport_ aux autres modules.
ConcrÚtement parlant, si tous les modules comportent un répertoire /admin avec 
les bonnes définitions de l'interface dedans, le module admin pourrait 
définir un évÚnnement

$ctrl->setUriEvent('^/admin', $admin);

pour se lancer, puis générer (cacher, tout ce que vous voulez) l'interface 
d'administration à partir des définitions contenues dans les autres modules.

Sinon vous pensez quoi de ce nouveau type d'évenement ?

> Je travaille au niveau des documents.
> J'ai décomposé le travail sur les documents en 2 étapes :
> - les plugins, qui ont un fonctionnement trÚs générique et qui sont
> capables de lister la donnée correspondant à une requete par type (pour
> les catégories par exemple)
> - les modules, qui mettent en forme la donnée renvoyée par le plugin et
> qui gÚre le cache au niveau donnée

D'accord; voilà comment je procÚderais moi dans un module particulier :
- les plugins dans /lib
- ensuite dans /init une classe principale (ce que tu appelle module) qui 
pourrait effectuer les actions spécifiques au module (ma définition)
- enfin un évenement dans le controleur du module pour lancer la classe 
précédente

Exemple pour le module core :
- dans lib j'ai des classes pour récupérer des articles, manipuler des 
fichiers joints, lister des catégories, etc.
- dans init j'ai la classe principale pouvant exécuter plusieurs actions 
(récupérer l'article X, le fichier joint Y, lister la catégorie Z, etc.) *à 
partir de l'uri*
- toujours dans init, je renseigne un évennement dans le controleur, du type
$ctrl->setUriEvent('*', $core);

Comme ça avec l'uri /CategorieTruc/ArticleMachin, le controleur passera 
automatiquement la main au module core défini ci-dessus, qui lui interprétera 
l'uri à sa maniÚre pour renvoyer l'article ArticleMachin de la catégorie 
CategorieTruc.

Bien sûr je pourrais définir cet évenement dans le module d'admin

$ctrl->setUriEvent('^/admin', $admin);

ce qui aurait pour effet de réserver la catégorie "admin" pour 
l'administration. Les possibilitées sont infinies ;-)

-- 
Olivier Pascal