Re: Test du nouveau type d'évenemen t

Olivier Pascal wrote:

>Le Mercredi 7 Avril 2004 16:24, Grégoire Cachet a écrit :
>  
>
>>c'est pas le but de l'application de fonctionner avec des posts par
>>emails, mais c'est une option dont on ne veut pas se priver ...
>>En gros, c'est pas pour tout de suite, mais on doit avoir une
>>abstraction suffisante pour l'implanter.
>>    
>>
>
>Disons que ça complexifie les choses pour pas grand chose on dirait. Tu as des 
>exemples d'autres interfaces, à part http et mail ?
>  
>
XML-RPC pour faire des taches d'application à distance et regénérer la 
config par exemple. Ca peut se faire par HTTP aussi, mais si on veut 
s'en servir pour regénérer l'arborescence, ca peut être utile de le 
découpler.
On peut aussi imaginer des flux de données provenant de sources externes 
en XML-RPC ou en SOAP.
Dans le cadre d'XML-RPC, on est pas obligé de faire passer les infos 
dans l'URI.

On peut également envisager une interface d'administration en dur, avec 
un logiciel graphique que tu execute sur ton ordinateur de la même facon 
que ton client mail ...

>  
>
>>L'URI, c'est adapté au HTTP, pas forcément à notre application.
>>    
>>
>
>En fait je proposais juste de standardiser la communication dans l'appli. Pour 
>gérer une autre interface on pourrait juste ajouter un module avant UriParser 
>pour convertir "lire tel article de telle section sans les commentaires" en 
>"/section/article?commentaires=non". C'est un bon compromis, AMHA. Ça 
>permettrait aussi de fonctionner sur plusieurs interfaces en parallÚle, http 
>et mail par exemple.
>  
>
c'est une possibilité, mais pas trÚs logique. UriParser est 
canoniquement liée à HTTP. Avoir un gestionnaire UriParser dans le cas 
d'une interface mail n'a pas vraiment de sens. Je pense qu'il faudrait 
mieux écrire une classe qui fait le même boulot que UriParser, mais dans 
le cas du mail !

Par exemple, un mail envoyé à [email protected] se traduit en une 
requete interne de post d'un message. C'est pas la peine de traduire en 
/Admin/Blog/NewPost !

En fait je ne concoit pas du tout l'application comme un site web. Bien 
sur elle sera capable de fournir ce que l'on appelle un site web, mais 
si je ne veux pas utiliser cette interface web, je ne suis pas obligé de 
le faire. Je pourrais ainsi me servir de blogv2 en local sans jamais 
ouvrir mon navigateur pour gérer les différentes versions d'articles que 
j'écris pour un journal papier par exemple !! Il suffira de contruire 
les interfaces adaptées.

>
>Bon 2 questions tant qu'on y est :-) Si j'ai bien compris le contrÃŽleur de 
>l'appli gÚre l'exécution des contrÎleurs des module selon un ordre relatif. 
>Là pas de problÚme. Maintenant prenons l'interface http : le contrÎleur va 
>initialiser UriParser, puis d'autres modules.
>
>Comment ces autres modules accederont à l'uri parsée (décomposée) ?
>  
>
c'est le concept de la requete interne. Il y aura un gestionnaire qui 
construira la requete interne, et ensuite les modules utiliseront cette 
requete interne qui ne sera rien d'autre qu'un objet PHP pour savoir ce 
qu'ils doivent faire.
On peut envisager UriParser comme un gestionnaire capable de transcrire 
une URI en requete interne.
Les gestionnaires suivants ne sauront alors rien sur la façon dont 
l'application a reçu la requete de la part du client.

>Je suppose que les modules devront interpréter l'uri chacun leur tour, puis 
>passer la main si ils n'en n'ont rien tiré (exemple du core qui pourrait 
>laisser la main si il tombe sur une uri destinée à l'administration).
>  
>

Voir ma proposition de définition des modules dans le mail que je viens 
d'envoyer.
Il va falloir effectuer un filtrage afin de savoir ce qu'on devra 
intégrer dans la page. Chaque brique logicielle gérant une donnée (ce 
que j'appelle module) déclarera : je travaille avec les catégories par 
exemple. S'il y a quelque chose qui ressemble à une catégorie, passez 
moi l'info !
Chaque module va déclarer cela dans sa description. Lors de la 
construction de l'application, DocumentHandler scannera ces 
déclarations, les triera selon les priorités afin de savoir directement 
qui doit faire quoi parmi ses modules quand l'utilisateur demande telle 
chose.
Lors de l'execution de l'application, quand DocumentHandler prendra la 
main, il analysera la requete interne et agira comme il l'avait prévu 
pour une requete de cette forme.

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