Fonction exit() et classe...

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : Fonction exit() et classe...

par AB » 12 oct. 2007, 14:07

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 ;)
Oup's j'avais arrêté ma lecture en bas de la première page :roll: :lol:

par Tracker » 12 oct. 2007, 12:43

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 ;)
Ou se baser sur la date de dernière modif du cache + un délai... (moins couillon ;))
a+

par Hubert Roksor » 12 oct. 2007, 12:42

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.

par jojolapine » 12 oct. 2007, 12:33

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 ;)

par Tracker » 12 oct. 2007, 12:07

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+

par jojolapine » 12 oct. 2007, 10:59

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 ;)

par AB » 12 oct. 2007, 10:50

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

par jojolapine » 12 oct. 2007, 10:18

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 :wink:
J'ai pas compris là... :roll:

par AB » 12 oct. 2007, 10:14

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 :wink:

par jojolapine » 12 oct. 2007, 00:57

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

par Hubert Roksor » 12 oct. 2007, 00:56

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"

par jojolapine » 12 oct. 2007, 00:41

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é?

par Hubert Roksor » 12 oct. 2007, 00:33

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é.

par jojolapine » 12 oct. 2007, 00:18

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 :langue:
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?

par Hubert Roksor » 12 oct. 2007, 00:09

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 ;)