Re: Mise au clair personnelle

Olivier Pascal wrote:

>
>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.
>  
>
pas trop d'accord : il vaut mieux exploser tout, ca sera beaucoup plus 
flexible. Quel est l'interet d'avoir un controlleur puissant qui gÚre 
les modules si c'est pour en avoir 2 ?? AMHA il faut mieux avoir tout le 
processus sur le même niveau.

>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 :
>
><snip />
>
>$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 ...
>  
>

si j'ai capté ;-) Mais ca ne me plait pas ... On peut pas mélanger 
URIParser avec la requete interne d'appel aux documents ... URIParser 
fait son boulot, il parse l'URI. Ensuite on analyse.

Cependant ton idée est bonne (et tout ce que tu poste dans les mails 
suivants). Je pense qu'on peut intégrer un truc du genre pour la requete 
interne. Toutefois, ca pose un problÚme. Si chaque type de document doit 
inclure ses propres trucs, ca peut vite faire beaucoup de monde à 
charger pour pas grand chose. Il faut donc indexer et construire ca en 
cache (le filtrage suivant ce que veut l'utilisateur).

>  
>
>>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 :-)
>  
>
pas d'accord ... On peut pas faire manipuler tout et n'importe quoi à 
l'admin. Il faut le décrire sinon ca peut pas marcher. Moi je considÚre 
que l'admin travaille sur le même plan que l'élément qui affiche un 
article sauf qu'elle fait autre chose. Et elle à besoin d'infos sur les 
différents éléments pour fonctionner.

>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 ...
>  
>
tout n'est que surcouche graphique dans l'appli. On peut sortir sous 
n'importe quel format la donnée. L'admin, c'est bien une fonctionnalité 
parmi tant d'autres de l'application.

>>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
>  
>
par exemple, je veux gérer les catégories.

Je créé un module *Categories* ? Ensuite dans /lib je mets mes plugins, 
dans init je mets mes modules ?
Ca ne fonctionne pas ... parce que justement les modules représentaient 
plusieurs moyens d'acceder à la donnée, et plusieurs /init ca ne colle 
pas !!

En gros, pour les catégories, j'ai mon plugin qui est capable de les 
lister. Ensuite, j'ai écrit un module SubCategories qui est capable de 
lister les catégories descendant d'une catégorie donnée. On peut 
envisager un module qui est capable d'afficher la description d'une 
catégorie, un module qui est capable de charger à la fois la description 
de la catégorie courante, mais aussi d'appeler un module  qui liste les 
articles de cette même catégorie.

>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.
>  
>
c'est pas au core d'interpreter l'URI ...


-- 
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/