CLASSE DE GESTION AVANCÉE DES COOKIES
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
-
16 avril 2007 à 01:37
marc660 Messages postés 171 Date d'inscription jeudi 15 avril 2004 Statut Membre Dernière intervention 18 juillet 2007 - 20 juil. 2007 à 01:18
marc660 Messages postés 171 Date d'inscription jeudi 15 avril 2004 Statut Membre Dernière intervention 18 juillet 2007 - 20 juil. 2007 à 01:18
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/42290-classe-de-gestion-avancee-des-cookies
https://codes-sources.commentcamarche.net/source/42290-classe-de-gestion-avancee-des-cookies
20 juil. 2007 à 01:18
19 juil. 2007 à 19:26
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
26 avril 2007 à 20:14
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 :)
26 avril 2007 à 15:37
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 ?
25 avril 2007 à 21:16
"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.
25 avril 2007 à 20:15
Ca te dit quelque chose le principe d'encapsulation ?
On ne doit jamais, je dit bien jamais mettre une propriété en public.
Jette un oeil sur cette article de Wikipédia : http://fr.wikipedia.org/wiki/Encapsulation_%28programmation%29.
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).
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.
25 avril 2007 à 19:16
En effet, et pour cela pas besoin de 30 get/set.
A partir du moment ou tu as 2 méthodes :
getTruc() return $this->truc;
setTruc($val) $this->truc = $val;
Y'a un problème.
Autant mettre la propriété en public.
"alors que la vérification de l'existence des méthodes getMachin() et setMachin($valeur) a lieu lors de la phase de compilation."
Totalement faux aussi. 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.
Y'a un bench pour prouver que get/set est plus lent ?
25 avril 2007 à 16:39
Quand je dis que "cela ne marche pas dans le cas où l'on utilise des noms de membres existants", c'est vrai, dans ton dernier exemple, "echo $object->array;" ne fonctionnera pas car le membre existe et sa visibilité es private.
Manuel PHP :
Les appels de méthodes et l'accès aux membres peuvent être surchargés via les méthodes __call(), __get() et __set(). Ces méthodes ne seront déclenchées que si votre objet, hérité ou non, ne contient pas le membre ou la méthode auquel vous tentez d'accéder.
25 avril 2007 à 15:33
Totalement faux.
Contre-exemple :
class x {
private $y;
public function get($var) {
return $this->$var;
}
public function set($var, $val) {
$this->$var = $val;
}
}
// Je passe volontairement sur les tests de détection de propriétées existantes où non.
$x = new x;
echo $x->y;
$x->y = 10;
echo $x->y;
Ca marche aussi bien.
Si tu as une classe qui possède 30getters, 30 setters... c'est qu'il y a un problème de conception de ta classe.
Moi je m'amuse pas à ca, la programmation n'est pas faite pour se compliquer la vie, mais bien de la rendre plus facile.
Moins rapide à l'éxécution ? Parce que tu trouves que :
public function getY() {
return $this->y;
}
C'est rapide ?
Ca ne sert strictement à rien ce genre de truc.
public function __get($var) {
if ( property_exists($this, $var) )
return $this->$var;
}
Mais généralement, tu utilises __get() quand tu as un tableau en propriété :
private $array array('x'> 'machin', 'y'=>'truc');
public function __get($var) {
if ( property_exists($this, $var) )
return $this->$var;
elseif ( array_key_exists($var, $array) )
return $this->array[$var];
else
throw new Exception(...);
}
Voila à quoi sert un Getter généralisé. A ne plus se faire chier avec 30 getters/setter qui remplissent des lignes inutilements.
25 avril 2007 à 14:09
Sinon, oui, la fonction getInstance est incorrecte : elle retourne une nouvelle instance à chaque appel, prend exemple sur celle de oox.
Dans un autre domaine, je ne pense pas qu'il soit mieux d'utiliser __get et __set que de créer des "getter" et des "setter" classiques, autant parce que c'est moins rapide à l'exécution que parce que cela ne marche pas dans le cas où l'on utilise des noms de membres existants (Name, Expiration, Variables).
22 avril 2007 à 12:19
private static $_instance = null;
public function getInstance()
{
if (self::$_instance null) self::$_instance new self();
return self::$_instance;
}
private function __construct() { ... }
16 avril 2007 à 16:22
$user = new Cookie('user', time() + 30);
et
$user -> setExpiration(time() + 30);
pourquoi ne pas intégrer le time() dans la méthode ça simplifie le truc...
$user = new Cookie('user',30); // temps de vie de 30 secondes
$user->setExpiration(-30); // cookie expiré depuis 30 secondes
Sachant qi'il est plus que rare de trouver un cookie dont le temps de vie est en secondes tu pourrais même passer le paramètre en minutes en intégrant un *60 dans ta méthode... .. .
@ tchaOo°
16 avril 2007 à 01:37
Utilise __get($var) et __set($var, $val) c'est tout aussi simple et rapide :)
$seen = $user->seen;
$seen++;
$$user->seen = $seen;
// ou :
$user->seen++;
Pareil pour le manager :
$user = $manager->nom_du_cookie;
Tu peux même garder en cache le contenu du cookie :
class manager {
public function __get($cookiename) {
if ( !isset(self::$_cookie[$cookiename]) )
self::$_cookie[$cookiename] = new Cookie($cookiename);
return self::$_cookie[$cookiename];
}
}
Ce qui permet par la suite :
$manager->nom_du_cookie->seen++;
unset($manager->nom_du_cookie); // détruira l'objet.
Tout ca tranquillement :)
Bref, quelques petits trucs à revoir (je précise que j'ai pas regardé le fichier source. J'ai juste regardé comment tu as présenté ton exemple.
En bref, je n'ai regardé que l'interface pour utiliser tes objets, pas le code en profondeur :))