Classe de gestion avancée des cookies

Soyez le premier à donner votre avis sur cette source.

Vue 6 222 fois - Téléchargée 368 fois

Description

Salut,
Pour un projet, j'avais besoin de gérer un nombres relativements importants de cookies de manière simple. Du coup, j'ai codé 2 classes : CookiesManager et Cookie. La classe CookiesManager permet de répertorier tous les cookies et les transforme en instance de la classe Cookie, plus simple à gérer qu'avec les fonctions natives de PHP, puisque qu'un grand nombre d'opérations sont simplifiées.
CookiesManager est un singleton, donc l'instance se récupère grâce à la méthode getInstance(). La fonction principale du gestionnaire est la possibilité de récuperer un cookie à partir de son nom grâce à la méthode getCookieByName($name).
Cookie est très simple a utiliser : lorsque l'on crée un nouveau Cookie, il va automatiquement s'ajouter à la liste des cookies du gestionnaires de cookies. La suppression d'un cookie se fait via la méthode delete(). On peut changer la date d'expiration du cookie via la méthode setExpiration($expiration), cet qui va impliquer une mise à jour automatique de toutes les variables du cookie ... Enfin, pour enregister une variable et récuperer, il faut utiliser les méthodes setVariable($key, $value) et getVariableValueByKey($key).
L'utilisation est donc très simple, et mieux vaut un bon exemple plutôt que de longues explications ...

Source / Exemple :


<?php
/* -------------------- */
   require_once('cookies/cookiesmanager.class.php');
   require_once('cookies/cookie.class.php');
/* -------------------- */
   $manager = CookiesManager :: getInstance();
   try
   {
      $user = $manager -> getCookieByName('user');
   }
   catch(NotExistingCookieException $e)
   {
      $user = new Cookie('user', Cookie :: END_OF_SESSION);
      /* Pour un cookie qui dure 30 secondes, on peut faire :
         $user = new Cookie('user', time() + 30);
         ou
         $user = new Cookie('user');
         $user -> setExpiration(time() + 30); */
      $user -> setVariable('name', (isset($_GET['name'])) ? $_GET['name'] : 'Visiteur');
      $user -> setVariable('seen', 0);
   }
   $seen = $user -> getVariableValueByKey('seen');
   $seen++;
   $user -> setVariable('seen', $seen);
/* -------------------- */
   echo '<pre>';
   $name = $user -> getVariableValueByKey('name');
   echo 'Salut à toi '.$name.', tu as vu cette page '.$seen." fois en 30 secondes ! \r\n";
   echo '</pre>';
/* -------------------- */
?>

Conclusion :


Alors je sais qu'il n'y a pas de commentaires ... En fait, j'en avais mis plein, mais j'ai tout effacé lors d'une première refonte. Mais je compte commenter et mettre à jour dès que j'ai un peu de temps :)
++ !
L.S.

Codes Sources

A voir également

Ajouter un commentaire

Commentaires

marc660
Messages postés
171
Date d'inscription
jeudi 15 avril 2004
Statut
Membre
Dernière intervention
18 juillet 2007
-
C'est pas grave
marc660
Messages postés
171
Date d'inscription
jeudi 15 avril 2004
Statut
Membre
Dernière intervention
18 juillet 2007
-
Bonjour,

Votre script ne fonctionne pas sur deux serveurs différent et aussi sur EasyPHP 2.0.0.0
Ou c'est une erreur ligne 8 dans index.php
Parse error: parse error, unexpected '{' in /homepages/30/d160718081/htdocs/Le-Facturier/teste/phpcs_CLASSE-GESTION-AVANC-201-COOKIES_42290/index.php on line 8

Ou sur un autre serveur ligne est EasyPhp Ligne106 dans cookie.class.php

Fatal error: Cannot use string offset as an array in D:\Program Files\EasyPHP 2.0b1\www\phpcs_CLASSE-GESTION-AVANC-201-COOKIES_42290\cookies\cookie.class.php on line 106


Comment corriger ce problème car je cherche un m?oyent d'enregistrer les valeurs des champs d'un formulaire.


Merci
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3 -
Je suis d'accord avec toi sur le fait d'évolution garanti avec l'encapsulation. Il est vrai qu'il est l'unique moyen d'être sûr à 100% que lors d'une modification de la classe, les choses marcheront toujours de la même facon.
Mais généralement, quand on utilise une propriété publique, c'est qu'on s'en fou un peu quand même.
Par exemple, une classe SQL. Tu peux récupérer le numéro de version du serveur MySQL, mais pas besoin d'un getter pour ca, il suffit de mettre la propriété en publique. Qu'importe de toute facon, elle ne fait rien de bien spécifique à la classe de toute facon.

Voila pourquoi je disais qu'il ne faut pas tout encapsuler :) Mais d'une manière générale oui il le faut.

Le statissisme, oui c'est l'espace de nom. C'est un concept objet également (bien que...).


L'autre problème que de faire du get/set, c'est qu'il faut créer l'interface qui va avec. Depuis PHP5, on associe les get/set avec une interface qu'on va inclure à la classe, et de ce fait on ne se reporte qu'à l'interface pour l'accès au méthode.

L'encapsulation est une bonne chose, mais doit être utilisé correctement :)
Gorrk
Messages postés
97
Date d'inscription
mercredi 16 avril 2003
Statut
Membre
Dernière intervention
26 avril 2007
-
Je suis désolé de mettre laissé emporter dans mon dernier message, je n'avais pas vu que tu était "le plus courtois possible" et "ouvert à tout débat", j'ai certainement mal interprété ton "totalement faux" car il m'a semblé que tu étais fermé et condescendant, et je m'en excuse donc.

Avant de clore cette discussion qui me semble stérile (désolé LocalStone de légèrement encombrer ton post), je souhaiterais revenir sur le principe d'encapsulation qui est, selon moi, un des principes les plus importants de la POO (avec l'héritage, le polymorphisme, ...) car c'est elle qui garantie l'évolutivité de ton code : si tu t'aperçois finalement que tu dois vérifier quelque chose lors de la mise un jour d'un membre, le fait de l'avoir déclaré public et de le modifier directement va compliquer la mise à jour de ton code et va (probablement) t'obliger à changer également les sources reposant sur ta classe pour, par exemple, remplacer la modif. directe du membre par une méthode chargée de la vérification. Alors que si tu utilisais depuis le début des méthodes d'accès, tu n'aurais qu'a la modifier quelque peu.

Sinon, qu'appelle tu le statissisme ? C'est le fait de regrouper des fonctions dans un espace de nom ?
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3 -
Youpi, jme suis trouvé quelqu'un à qui parler !

"Tu connais les principes de la POO ?"
Non, je ne connais absolument rien de la POO, tu as totalement raison.

"Ca te dit quelque chose le principe d'encapsulation ?"
Le principe d'encapsulation n'a jamais obligé le developpeur a n'utiliser exclusivement le private/protected et a bannir le public.
Il est certe utilisé pour faire une "boite noire" pour chaque instance de classe, et cela est utile lorsque l'on veut filtrer les données entrantes.

Cependant, l'orientée objet n'oblige pas l'utilisation de ce principe, et c'est bien là où tu fais erreur. Pour toi, objet = principe d'encapsulation. C'est totalement faux. Je n'ai jamais entendu rien de tel jusqu'à présent.
L'utilisation du statissisme par exemple ne fait pas partie du principe d'encapsulation.
Avant de me balancer le principe d'encapsulation en pleine tronche simplement pour faire beau, fais attention à ne pas faire l'analgame : "je fais un objet, j'utilise forcément le principe d'encapsulation".

"Sur le second point, tu mélange absolument tout, je parle d'une méthode getMachin(), pas d'une méthode get($machin), car évidemment, dans cette dernière version, c'est équivalent à __get($machin)."
J'avoue que même en me relisant, je ne comprends toujours pas ce que tu viens de me dire. Ah si ca y est :
"Je peux faire une méthode qui va faire un get() sur une propriété inexistante, et l'erreur ne se produira que lors de l'appel de la méthode erronée."
Il fallait y lire :
"Je peux faire une méthode qui va faire un getMachin() sur une propriété inexistante, et l'erreur ne se produira que lors de l'appel de la méthode erronée."

"Alors, avant d'affirmer que quelque chose est "totalement faux", essaie de comprendre ce que te dis ton interlocuteur et renseigne toi sur le fonctionnement d'un interpréteur/compilateur."
Ouh, alors la c'est dur comme critique. Je ne pensais pas que quelqu'un irait jusque la. Je pensais qu'avoir fait des sources largement orientées objet ici me prémunirais contre ce genre d'attaque infondée.


J'ai autre chose à branler que de venir cracher sur toi ou sur quiconque. Car, si c'est bel et bien à cela que tu te destines en voulant te confronter à moi, sache que je suis pret à changer le ton de mes réponses.
Pour le moment, je me veux le plus courtois possible. Ce n'est pas parce que j'ai dis que ton raisonement était faux que j'ai dis que tu étais un pauvre naze et qu'il fallait que tu fermes ta gueule parce que tu avais tord.

Je suis ouvert à tout débat, en particulier sur la POO, tant que cela reste dans le cadre du respect. J'ignorerai donc tes attaques personnelles cette fois ci, mais si cela revient à recommencer une nouvelle fois, je n'hésiterai pas à passer moi aussi à l'offensive.

Mais pour le moment, le niveau de mes sources comparé aux tiennes me confortent dans l'idée que pour le moment, je ne crains absolument rien de ta part :)


Sur ce, je mentiens ce que je dis. En effet, tu n'as pas réussi à me convaincre du mal-fondé de mes pensées... en tout cas pas avec 4 phrases chocs et un lien sur wikipedia :s
Si tu comptes me faire valoir ton point de vue, il va falloir trouver mieux.

Je suis ouvert à tout.

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.