donc on avait bien identifié la source de l'erreur...

Je ne suis pas sûr qu'on parle de la même chose. Le message d'erreur indique que le dossier n'existe pas. C'est parce que durant la fin du script, au moment où l'output buffering stoppe automatiquement, le répertoire en cours est remis à zéro donc ton "./" ne correspond pas à ce que tu crois. Ton self::DOSSIER doit être un chemin absolu (au pire tu peux déterminer son chemin absolu avec realpath() en dehors de ob_end()).

je reviens voir les propriétés et paf, il est de nouveau en lecture seule

Je ne pense pas que ton dossier soit vraiment en lecture seule, en tout cas pas si tu as déjà fait marcher file_put_contents() dedans. Le bouton auquel tu fais référence possède 3 états (on, off, default, si mes souvenirs sont bons), clique dessus trois pour voir les trois, le "carré vert" correspond au réglage par défaut.

En tout cas merci encore de t'intéresser à mon cas

Noprob. Au fait, je repasse régulièrement sur les sujets auxquels je participe, donc ne t'angoisse pas si tu ne peux pas le remonter trop souvent.

Youpii la boum!!!!
A priori, le problème est [résolu], grace à realpath()...
Bon après j'ai pas regardé en détail, j'ai codé en vitesse car il se fait tard...
Sinon ben je croit que j'assimile encore assez mal les notions de buffurisation..., pourquoi lorsqu'on utilise un buffer, et qu'on reste dans un même script, les chemins relatifs ne pourraient pas fonctionner?
Bon je vais fignoler la classe demain et si j'arrive à bien avancer, j'irais peut-être faire un tour dans le fofo "vos contributions"...
Encore milles merci, et toutes mes excuses pour la "remontée de sujet"...
Et pour le dossier en lecture seule, j'ai compris mon erreur, c'était bien l'option par défaut qui était selectionnée
bonne nuit!!

En fait ton problème n'était pas vraiment avec la bufferisation, mais plutôt avec l'exécution de code en fin de script. Je ne pense pas que tu aurais eu le même problème si tous ton script s'était terminé par ob_end_flush() (ce qui, en dehors du cas présent, n'est pas forcément une bonne idée). Sans arrêt explicite de la bufferisation, tout se déroule lors de l'arrêt du script, ce qui change pas mal la donne (notamment le répertoire en cours, comme tu as pu le voir). C'est un problème partagé par __destruct() et register_shutdown_function() d'ailleurs.

Enfin, content que tu t'en soies sorti

Et donc tu pense qu'il vaut mieux que je reste comme ça pour le code, ou que j'utilise ob_end_flush ?
en fait j'ai pas très bien compris le

(ce qui, en dehors du cas présent, n'est pas forcément une bonne idée)

Tu veux dire que là ça pourrais être bien? voir mieux?

Et t'inquiète pas, moi aussi je suis content
Et je trouve que c'est une manière assez "simple" et élégante de cacher ses pages.
Et je me demandais en plus... est-ce que avec la fonction ob_end d'appelée, le flux est compréssé en sortie ou non? si non est-ce que c'est possible de rajouter ob_gzhandler dans ma fonction ob_end, est-ce que c'est utile?

j'ai pas très bien compris le [...]

Je disais qu'appeler ob_end_flush() systématiquement n'était pas forcément une bonne idée. PHP le fait automatiquement en fin de script si nécessaire.

si non est-ce que c'est possible de rajouter ob_gzhandler dans ma fonction ob_end, est-ce que c'est utile?

C'est utile si tu veux compresser tes pages et si le serveur ne le fait pas déjà. Tu peux imbriquer les ob_start() si tu veux, par exemple

ob_start('ob_gzhandler');
ob_start('ob_end');

...ou probablement appeler ob_gzhandler() directement dans ob_end()

function ob_end($contents)
{
	file_put_contents($contents, self::FILE);
	return ob_gzhandler($contents);
}

...ou encore utiliser le paramètre zlib.output_compression de php.ini, dans le cas d'un serveur dédié.

Merci pour tout ces éclairements (ça se dit?)...!!
Je vais utiliser zlib.output_compression, je n'ai pas un dédier, mais j'ai la mains sur quelques variables du php.ini, dont celle-ci, donc je la met à on, et ensuite toute mes pages (même celle qui n'ont pas de buffurisation seront compressée...
Pourquoi par défaut ce paramettre est à off? aussi bien sur wamp en local que sur mon mutualisé?

La compression demande un traitement supplémentaire, certains prestataires préfère économiser leur CPU au maximum, quitte à utiliser un petit peu plus de bande passante.

PS: "éclaircissements"

Merci pour tout!!!
Maintenant au lit... parce que sauf si tu habites au canada, il commence à se faire tard

Ben si peu de gens prennent le temps de te répondre c'est soit qu'ils ne savent pas te répondre (ce qui est mon cas) et pour les autres peut-être aussi parce que c'est tagué RESOLU

Ben si peu de gens prennent le temps de te répondre c'est soit qu'ils ne savent pas te répondre (ce qui est mon cas) et pour les autres peut-être aussi parce que c'est tagué RESOLU

J'ai pas compris là...

Je voulais dire que quand on cherche à aider les gens, on ne commence pas par ceux qui à priori n'en n'ont pas besoin
Et à priori quand c'est tagué résolu c'est que le pb est résolu, non ?

oui mon post est taggé résolu depuis cette réponse: http://www.phpfrance.com/forums/voir_re ... php#215362
et après cette réponse, je ne me suis plus plain du manque de réponse...
J'ai juste des petits éclaircissements supplémentaires à Hubert

Salut,

Je me posais une question en lisant tes posts hier. Les échanges que tu as eus avec hubert depuis quelques jours ont finalement mis en place ton idée de départ. Seulement c'est celle-ci que j'ai du mal à comprendre. Dans ton système, tu n'introduis nullepart un notion de "durée de validité" pour ton cache, ce qui rend le principe bancal:
Une fois "cachée" ta page devient statique, alors pourquoi ne pas l'avoir directement produite en (x)html ?

Je pense qu'il manque une gestion claire, dans la classe de cache, de la peremption.
Pour être un peu concrêt, je pense que tes fichiers xxx.cache.html doivent contenir au moins une autre information: la date à partir de laquelle les infos deviennent inutilisables.
Ta méthode Cache::ob_end pourrait s'écrire:

class Cache
...
   function ob_end($contents)
   {
        file_put_contents($filename, serialize(array('date' => $this->endDate, 'contents' => $contents)));
        return $content;
    }
...

Et gérer l'info 'date' dans ta méthode Cache::initCache(...)
Le seul truc un peu couillon, c'est que tu devras lire l'intégralité du fichier de cache même si ce dernier est périmé...
a+

Pour répondre à ta question, en fait je n'introduis pas de notion de "péremption" dans mes fichiers cache, pour la simple raison que les fichiers de caches sont supprimés automatiquement lors de leurs modification...
Par exemple, pour une page de news, un fichier de cache est généré, et il sera supprimer lorsque j'ajouterais une news dans la partie admin...
Donc pas besoin de date de validitée...
sinon

Le seul truc un peu couillon, c'est que tu devras lire l'intégralité du fichier de cache même si ce dernier est périmé...

Une alternative serait de stocker le timestamp de péremption dans le nom du fichier, du style:
nomdufichier.timestamp.ext, ainsi tu n'as plus qu'a faire un traitement sur le nom et non plus sur le contenu

tu n'introduis nullepart un notion de "durée de validité" pour ton cache

Tous les caches n'expirent pas forcément après une période donnée, on peut les invalider de différentes façons. Par exemple, imagine un guide touristique où chaque page recense une région et ses lieux culturels sous la forme d'URLs "/123-Loire/Châteaux", "/123-Loire/Musées", etc... Dans l'interface d'administration, si on met à jour les infos des Châteaux de la Loire, on efface le fichier "123_Loire_Châteaux.html". Ou si on met à jour des informations générales sur la Loire, on efface tous les fichiers "123_Loire_*.html". Les fichiers de cache sont effacés à chaque modification potentielle (inutile de vérifier si les modifications affectent réellement la page, parce que la vérification coûte aussi cher que la génération) puis régénérés la prochaine fois que la page correspondante est demandée.

Quelques notions rapides : le processus qui consiste à faire expirer des données mises en cache s'appelle l'invalidation. La durée de vie d'un cache (si applicable) est abbrégée TTL pour Time To Live. Je ne sais pas si le terme existe, mais j'ai toujours appelé un cache dont les données sont toujours valides (comme l'exemple donné plus haut) un cache "pertinent", parce que ses données sont toujours pertinentes (fresh) alors qu'un cache basé sur un TTL peut servir des données périmées (stale).

Comme la classe de jojolapine le montre, mettre des données en cache est le plus facile, ça prendre 40 lignes avec les commentaires et en sautant des lignes. L'opération la plus délicate est l'invalidation, sachant qu'en utilisant un système d'invalidation ou de gestion trop complexe on peut perdre tout avantage à utiliser un cache.