[PHP5]CLASSE DE TEMPLATE PHP AVEC CACHE
coucou747
Messages postés
12303
Date d'inscription
mardi 10 février 2004
Statut
Membre
Dernière intervention
30 juillet 2012
-
17 juin 2007 à 19:01
FhX Messages postés 2350 Date d'inscription mercredi 13 octobre 2004 Statut Membre Dernière intervention 18 avril 2015 - 26 juin 2007 à 08:53
FhX Messages postés 2350 Date d'inscription mercredi 13 octobre 2004 Statut Membre Dernière intervention 18 avril 2015 - 26 juin 2007 à 08:53
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/43148-php5-classe-de-template-php-avec-cache
https://codes-sources.commentcamarche.net/source/43148-php5-classe-de-template-php-avec-cache
26 juin 2007 à 08:53
25 juin 2007 à 20:54
25 juin 2007 à 15:56
D'après ce que j'ai lu, il semblerait que ce soit pour PHP6.
Peut être :)
25 juin 2007 à 14:56
je ne parlais pas seulement de l'overloading de functions, mais aussi d'operator, faire :
$a=new Vector(1, 3, 5);
$b=new Vector(5, 3, 1);
$c=$a+$b;
comme on peut le faire en Cpp... moi ca me manque (d'autant plus que j'ai fait quelques classes lignes pour positionner des points en "live")
25 juin 2007 à 14:45
Si on utilise les propriétés publiques, on se doute bien qu'au final il n'y aura pas d'évolution dans ce domaine. Je m'explique.
Prenons le cas d'une propriété de débug. Pas besoin de get/set pour du débug, on s'en carre le cornichon :)
Même si il y a évolution du projet derrière :
class x {
public $debug = false;
//
}
class y extends x {
//
}
$y = new y;
$y->debug = true;
Bon et voila :)
Dans ce cas la, le "public" fonctionne très bien et tu n'as pas besoin de faire :
$y->setDebug(true); ou $y->ActiveDebug();
C'est une perte de temps :o
Comme dit Coucou, ce qui manque, c'est la redéclaration des méthodes. Rien de plus beau (comme en Java) de faire :
public function __construct($var);
public function __construct($var, $truc);
public function __construct(Object $x, Object $y);
Sans avoir à se faire chier avec func_*() et autre fonction de ce genre.
Le namespace, tu peux y arriver via le statissisme :
class x {
static public function x1();
}
x::x1();
Et tu peux très bien arriver à un résultat de ce genre :
x::x1()->...()->...->...::...()->...();
Techniquement, je crois que ca passe.
Pour en revenir plus, chacun est libre de faire comme il veut.
Pour ma part, c'est simple :
abstract class Item {
public $debug = false;
}
abstract class Factory extends Item {
//
}
abstract class Element extends Item {
//
}
class NewsFactory extends Factory {
//
}
class News extends Element {
//
}
Pas besoin de m'ennuyer avec des méthodes qui servent à rien :)
25 juin 2007 à 12:56
en general, disons que moi, ce qui me manque terriblement, c'est la surcharge d'operateurs, et les namespaces.
pour ton projet, je crois que tout a ete dit
25 juin 2007 à 12:43
25 juin 2007 à 11:25
25 juin 2007 à 10:17
En fait les get/set ont d'autres raisons d'être systématiques; par exemple, quand on met à jour la valeur d'un attribut, il peut y avoir d'autres choses à faire (test de valeurs limites, autre(s) attribut(s) à modifier, etc.). Si ce n'est pas le cas, rien ne dit que les évolutions de l'application ou de l'objet n'amèneront pas ces contraintes. Si on n'a pas mis les get/set, il faut modifier tout le code qui modifie les attributs publiques...
Enfin, la philosophie objet (en tous les cas tel que je la perçois) dit que l'on doit utiliser un objet comme une boite noire, donc que l'on n'a pas savoir ce qui se passe dedans, donc les attributs en private et des get/Set.
20 juin 2007 à 16:15
"Une classe se définit ainsi : 1 nom, des données membres (attributs), 1 constructeur et des méthodes."
Pour ca, on est tous d'accord. On peut rajouter quelques trucs, mais la base y est.
"Il appelle donc l'action avalerMedicament() qui va mettre à jour l'état de son foie mais il ne peut pas appliquer directement $corpsHumain->foie = 'truc'"
Pourquoi ? Parce que ta méthode avalerMedicament fait appel à d'autres procédés avant d'arriver à une purification de ton foie. Voila pourquoi ta propriété foie doit être privé/protégé dans ce cas précis.
Maintenant, jouons la autrement.
Notre foie est toujours malade. Mais nous allons ajouter une propriété "auto_soin_foie" qu'on va mettre à vrai.
Hors, pour une raison X ou Y, on se retrouve avec : $corpsHumain->auto_soin_foie = false;
Mais de toute facon, que la réparation du foie soit automatique ou non, on va faire avaleMedicament().
Ici, auto_soin_foie n'a pas besoin d'être privé, car, bien que son comportement influe sur l'instance, il n'est pas nécessaire de faire un controle strict dessus.
Pas la peine de faire :
public function setAutoSoin($var) {
$this->auto_soin_foie = (bool) $var;
}
public function getAutoSoin() {
return $this->auto_soin_foie;
}
La par exemple, le privé/protégé ne sert à rien.
Si tu me dis "nan on ne controle pas ce qui rentre..." bien sur que si, c'est du vrai/faux. Et regarde, si je jète un oeil à ma méthode avaleMedicament(), j'ai ca :
if ( (bool) $this->auto_soin_foie ) {
//
} else {
//
}
J'ai réglé tout mes problèmes.
Pour un traitement de nombres/chaines/objets/flottants etc... tu peux/doit passer par du get/set, surtout à cause du set.
Pour un traitement en booléan, bof bof :)
19 juin 2007 à 09:36
à bien écouter, remarques, on comprend un peu mieux ^^
19 juin 2007 à 09:30
19 juin 2007 à 08:30
L'utilisation d'un setter aide pour la mise en place d'un poka-yoké (http://www.nexen.net/articles/dossier/15024-le_filtrage_poka-yoke.php). Une mise à jour s'impose ;p
19 juin 2007 à 06:00
animaux mamiferes etc.
19 juin 2007 à 00:12
19 juin 2007 à 00:07
Une classe se définit ainsi : 1 nom, des données membres (attributs), 1 constructeur et des méthodes. Quand tu définis une classe, tu modélises un objet. Cet objet a ses propres propriétés (attributs) et ses propres actions (méthodes). En déclarant tes attributs privés, tu forces la visibilité et l'accès à ces derniers par l'objet lui même. Seul l'objet doit pouvoir mettre à jour ses données membres via l'utilisation de setter(). Je prends un exemple métaphorique, peut-être peu approprié mais qui illustre ce principe.
Prends un être humain. Le+ corps humain est composé d'organes (ses attributs) et est capable d'agir (courrir, respirer, marcher, réfléchir). On visualise donc ici une modélisation schématique du corps humain composé d'attributs et de méthodes. Admettons que le corps humain d'une personne tombe malade. Le foie (attribut) est touché par une hépatite C. Comment le guérir ? Solution pour le patient : il doit avaler différents médicaments. Dans ce cas, cela signifie que seul lui même peut se guérir en avalant un médicament. Il appelle donc l'action avalerMedicament() qui va mettre à jour l'état de son foie mais il ne peut pas appliquer directement $corpsHumain->foie = 'truc'
J'essaie de montrer par cet exemple un peu tiré par les cheveux, l'intérêt d'utiliser des setters pour mettre à jour les attributs d'une classe.
++
18 juin 2007 à 15:09
Avec cette classe il est possible de gérer un système de thème et de mettre en cache.
Je ne vois pas en quoi je "remplace" echo(), si j'aurais voulus remplacer echo(), j'aurais utiliser print() :)
18 juin 2007 à 14:25
18 juin 2007 à 13:52
18 juin 2007 à 13:20
utiliser un truc complique avec d'autres balises, ca fait un systeme plus souple, plus propre, plus modifiable, etc...
18 juin 2007 à 13:15
18 juin 2007 à 12:43
18 juin 2007 à 09:35
Antoine de Saint-Exupéry.
Pourquoi rajouter un setter alors qu'avec l'attribut public, nous pouvons accéder au variable de la session ? Surtout que c'est pas comme si c'était un identifiant de base de donnée ou tout autre variable critique...
Pourquoi rajouter un système de pseudo language, le but est d'utiliser le moins possible de ressources, de codes, de méthodes... Actuellement, l'imbrication est effectivement illimité et je ne vois pas le rapport avec "j'ai pas code la fonctionalite, j'ai pose du scotch, et ca tient, si ca tombe, je poserais une agraphe". D'ailleurs, les requêtes ne doivent pas être executer par la Vue mais par le ModelDAO... j'aime bien séparé les différentes choses...
A+
17 juin 2007 à 22:13
$user_list_render = $tpl->render('user_list.php');
$tpl->setVar('user_list_render', $user_list_render);
c'est tres "j'ai pas code la fonctionalite, j'ai pose du scotch, et ca tient, si ca tombe, je poserais une agraphe"...
enfin on aurait pu penser a un tag genre {template "machin.tpl"} avec des options genre pour un resultat de requette : {template "machin.tpl" requetteNom -All} ou {template "machin.tpl" requetteNom -Limit 1 to 10} voir encore {template "machin.tpl" requetteNom -Once}
et des variables genre {variable ici}
ou une combinaison : {template "machin_{variable}.tpl" requetteNom -Once}
17 juin 2007 à 22:02
<?php
$tpl = new Template('monTemplate.tpl');
?>
Sinon je plussoie Coucou747 par rapport aux tags que tu utilises.
++
17 juin 2007 à 20:08
Merci :)
17 juin 2007 à 19:01