Dans le ticket portant sur le cache, http://developer.jelix.org/ticket/4, Laurent, tu indiques privilégier une approche par méthode à l'objet response plutôt que par plugin.

De prime abord, il me semblerait préférable que ce soit implémenté sous forme de plugin car ça me parraitrait plus simple pour le développeur.

Est-ce le fait de vouloir pouvoir déterminer dynamiquement la date de dernière modif des données qui t'emmènes à vouloir gérer çà au via une méthodes de jResponse. Si c'est le cas, n'est ce pas possible de passer en plugins params (selon le cas): soit un délais de rafraîchissement du cache soit un pointeur de fonction (fonction qui servirait à déterminer la date/heure de la dernière modif du contenu).

Par ailleurs comment voit tu l'identification des données cachées ? Un hash basé automatiquement sur l'ensemble des paramètres de la requête HTTP ? N'est il pas souhaitable de laisser au développeur la possibilité d'indiquer quels sont les paramètres de la requête qu'il convient de prendre en compte un peu comme pour les zones ?

Enfin, ne faudrait t'il pas commencer par créer une classe JCache générique qui permettrai de faire du cache de tout ce qu'on veut (du moins de tout contenu stockable sous forme de fichier) et d'utiliser cette classe pour le cache au niveau du controller, le cache des zones et éventuellement du cache au niveau des DAO. En parcourant les forums j'ai cru comprendre qu'il y avait qqch comme ca dans Copix et que ça te paraissait trop compliqué à utiliser. Dans mon idée, la complexité de JCache serait masquée par les différentes implémentations (zone, controlleur, dao)

Merci de ton feedback. A vrai dire je me tate pour me lancer dans un système de cache relativement simple, mon besoin étant de mettre en cache des données Json renvoyées par mes actions.

il me semblerait préférable que ce soit implémenté sous forme de plugin car ça me parraitrait plus simple pour le développeur.

Impossible, car l'implémentation d'un tel plugin sera beaucoup beaucoup trop compliqué.

Et je vois pas en quoi l'appel à une méthode est plus compliqué que de paramétrer dans tout les sens un plugin...

Est-ce le fait de vouloir pouvoir déterminer dynamiquement la date de dernière modif des données qui t'emmènes à vouloir gérer çà au via une méthodes de jResponse

Oui, c'est ce qu'il y a de plus pertinent à mon sens.

Si c'est le cas, n'est ce pas possible de passer en plugins params (selon le cas): soit un délais de rafraîchissement du cache soit un pointeur de fonction

Donc ça revient au développeur à développer une fonction, donc lui faire au moins autant de chose que dans l'autre solution.

Par ailleurs comment voit tu l'identification des données cachées ? Un hash basé automatiquement sur l'ensemble des paramètres de la requête HTTP ?

Non, c'est le navigateur qui envoi des informations sur son cache. Il n'y a donc pas de hash à gérer, pas de cache coté serveur à gérer ou je ne sais quoi d'autres (à moins que j'ai loupé quelque chose ?)

N'est il pas souhaitable de laisser au développeur la possibilité d'indiquer quels sont les paramètres de la requête qu'il convient de prendre en compte un peu comme pour les zones ?

C'est exactement ce qu'il peut faire avec ma méthode : libre à lui d'appeler ou non la méthode activateHttpCache() selon ce qu'il reçoit en paramètre (donc de tenir compte ou non du cache que le navigateur a).

Enfin, ne faudrait t'il pas commencer par créer une classe JCache générique qui permettrai de faire du cache de tout ce qu'on veut

Si tu veux, mais elle ne servirai strictement à rien avec ma méthode. Il n'y a pas de cache à gérer coté serveur, et c'est justement l'avantage de ma solution : on utilise pleinement les possibilités de HTTP.

En parcourant les forums j'ai cru comprendre qu'il y avait qqch comme ca dans Copix et que ça te paraissait trop compliqué à utiliser.

Je n'en avais pas besoin dans le core de jelix, et n'en ai toujours pas besoin. C'est pour ça que je l'avais viré, et que je ne l'ai toujours pas réintroduit.

A vrai dire je me tate pour me lancer dans un système de cache relativement simple, mon besoin étant de mettre en cache des données Json renvoyées par mes actions.

Lance toi alors :-) et propose ta classe jCache (mais tu crée un autre ticket ;-) ).

il me semble néanmoins pertinent d'avoir une classe jCache permettant de cacher ce qu'on veut et notamment des choses en input

C'est pour ça que je te propose de proposer ta classe de cache dans un ticket ;-)