Re: Test du nouveau type d'évenemen t

Olivier Pascal wrote:

>Je veux bien faire une classe pour récupérer / envoyer des mails mais j'ai 
>quelques questions d'abord :
>
>- à quoi ça sert de pouvoir effectuer des opérations sur blogv2 par email ? si 
>on peut le faire par email on peut le faire par l'interface web ! A part si 
>on a un gsm qui permet d'envoyer des emails mais si c'est le cas alors il 
>permet probablement de surfer sur le wap aussi; et pour les gsm qui n'ont pas 
>l'option email, certes on peut en envoyer via des textos mais globalement je 
>ne vois pas trop l'intéret pour taper un billet de plus d'une dizaine de 
>caractÚres ... vous m'éclairez ?
>  
>
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.

Ce que je propose pour avoir différentes interfaces, c'est de faire 
différents fichiers d'initilialisation spécialisés et de passer le type 
au controleur (interface web pour l'instant)

Quand on travaille en mode web, il suffit de connecter apache sur ce 
fichier via un mod_rewrite.
Si un jour on veut travailler à partir des mails, on fait un pipe dans 
/etc/aliases et on connecte l'arrivée du mail au fichier 
d'initialisation de l'application qui gÚre les mails.

>- pour faire exécuter des actions par d'autres moyen que l'interface http, on 
>ne pourrais pas générer la bonne url avant le traitement (par exemple générer 
>l'url correspondante à l'insertion de l'article reçu par mail), 1) ça 
>éviterais d'avoir des évÚnements de tous types dans les fichiers xml des 
>modules et d'avoir à en rajouter à chaque fois et 2) ça permettrait de 
>n'avoir plus qu'à gérer un seul type d'évenement
>
>  
>
L'URI, c'est adapté au HTTP, pas forcément à notre application.
Tout d'abord en interne on travaille avec des objets PHP : une URI n'est 
pas un objet PHP. Ensuite, l'URI est trop flexible et il faut qu'un 
élément spécialisé de l'application fasse le tri de l'information 
qu'elle contient : ca n'est pas au gestionnaire de documents de s'en 
charger ...

Par exemple, tu proposais un filtre ^/blogv2/(.*). C'est bien si 
l'utilisateur veut la langue par défaut, mais s'il force l'utilisation 
de l'application en anglais, ca ne fonctionne plus :
/en/blogv2/truc

Voila pourquoi le gestionnaire de documents ne doit pas se charger de 
traiter des URI : ca n'est pas son boulot !

-- 
Grégoire Cachet