Bonjour à tous,
pour faire suite au sujet :
http://fr.piwigo.org/forum/viewtopic.ph … 83&p=3
je vous propose de discuter des évolutions possibles. Voici par exemple ce que contient le fichier maintain.inc.php actuel (thème montblanc):
<?php function theme_activate($id, $version, &$errors) { global $prefixeTable, $conf; if (!isset($conf['MontblancXL'])) { $config = array( 'home' => true, 'categories' => true, 'picture' => false, 'other' => true, ); conf_update_param('MontblancXL' , addslashes(serialize($config))); } } function theme_deactivate() { conf_update_param('MontblancXL' , null); }
Voici celui que je propose :
<?php class theme_montblancxl extends themes { public static $theme_id = 'montblancxl'; public static function activate($id, $version, &$errors) { if (!isset($conf['MontblancXL'])) { $config = array( 'home' => true, 'categories' => true, 'picture' => false, 'other' => true, ); conf_update_param('MontblancXL' , addslashes(serialize($config))); } } } ?>
Qu'est-ce qui est le plus complexe ? Dans la deuxième version, on n'a pas besoin de définir la fonction deactivate(), elle est hérité de la classe mère.
Gotcha a écrit:
Tout à fait d'accord aussi.
J'en bave déjà assez rien qu'à recopier/adapter ^^
L'idée est d'encore plus simplifié le boulot de ceux qui font des thèmes ou des plugins. J'ai présenté cela pour les thèmes mais on peut imaginer le même genre de choses pour les plugins. On n'écrit que ce qu'on particularise pour son propre thème/plugin. Le reste est hérité.
Qu'en pensez-vous ?
p.s: Je n'ai pas mis la discussion dans le forum anglais car d'une part je tiens à ce que la maximum de personnes participe et d'autre part elle a été initié en français. Quand on discutera d'une éventuelle implémentation, on créera la discussion sur le forum anglais.
Dernière modification par nicolas (2010-04-14 16:59:24)
Hors ligne
nicolas a écrit:
je tiens à ce que la maximum de personnes participe et d'autre part elle a été initié en français.
Dans ce cas, explique un peu de quoi il retourne, car pour celui qui débarque (dont moi), il n'est pas évident de savoir à quoi ça sert !
Hors ligne
tosca a écrit:
nicolas a écrit:
je tiens à ce que la maximum de personnes participe et d'autre part elle a été initié en français.
Dans ce cas, explique un peu de quoi il retourne, car pour celui qui débarque (dont moi), il n'est pas évident de savoir à quoi ça sert !
Je dois avouer que c'est peut-être un peu trop technique. Du coup je ne sais pas quoi te dire. C'était pour savoir si ma proposition semblait vraiment plus complexe que l'actuelle.
Hors ligne
nicolas a écrit:
Je dois avouer que c'est peut-être un peu trop technique. Du coup je ne sais pas quoi te dire. C'était pour savoir si ma proposition semblait vraiment plus complexe que l'actuelle.
S'il ne s'agit que de faire du copier/coller, les deux méthodes me paraissent peu différentes.
Mais pour celui qui voudra créer son thème, il faudra bien lui dire ce qu'il fait de ce truc-là ! Où il le met, ce qu'il peut/doit modifier dedans, etc.
Hors ligne
J'ai rédigé un post un peu similaire ([Forum, topic 17502] de l'usage de la programmation objet et autres) avant de voir celui-ci, ou j'essaye d'expliquer un peu l'avantage d'utiliser des classes.
Juste par rapport à ton exemple, pourquoi faire des méthodes statiques ?
Hors ligne
nicolas a écrit:
tosca a écrit:
nicolas a écrit:
je tiens à ce que la maximum de personnes participe et d'autre part elle a été initié en français.
Dans ce cas, explique un peu de quoi il retourne, car pour celui qui débarque (dont moi), il n'est pas évident de savoir à quoi ça sert !
Je dois avouer que c'est peut-être un peu trop technique. Du coup je ne sais pas quoi te dire. C'était pour savoir si ma proposition semblait vraiment plus complexe que l'actuelle.
C'est surtout que 95% des personnes qui souhaiteront réaliser un thème aux couleurs qui les intéressent s'arrêteront au fichier css ;-)
Concernant le côté technique, même si moi je comprends ce que tu as écrit, je t'avoue que sorti du contexte d'exploitation des dites classes, il est difficile de comprendre.
dans la méthode de P@t, la fonction "theme_activate" existe, elle est utilisé.
Avec une classe, celà nécessite de connaitre le nom de la classe. C'est déjà moins évident. Il faut donc en amont mettre un mécanisme de déclaration de la classe, ou quelque chose comme çà je suppose.
Hors ligne
grum a écrit:
Concernant le côté technique, même si moi je comprends ce que tu as écrit, je t'avoue que sorti du contexte d'exploitation des dites classes, il est difficile de comprendre.
C'est ce que je dis plus ou moins dans l'autre fil : c'est bien le contexte le plus difficile à appréhender :/
Hors ligne
nicolas a écrit:
L'idée est d'encore plus simplifié le boulot de ceux qui font des thèmes ou des plugins. J'ai présenté cela pour les thèmes mais on peut imaginer le même genre de choses pour les plugins. On n'écrit que ce qu'on particularise pour son propre thème/plugin. Le reste est hérité.
C'est extrêmement complexe comme méthode (meme si je reconnais que c'est super).
Comme grum, je comprend techniquement ce que tu as écrit (et encore, j'ai eut un peu de mal!), mais c'est à mon avis complètement incompréhensible pour le programmeur en herbe qui veut créer son thème...
Pour l'instant, le seul interet de cette méthode est de ne pas définir la fonction deactivate...
Est-ce qu'on pourrait trouver un exemple un peu plus interessant? Grum, vois-tu quelque chose qu'on peut faire avec la méthode de nicolas et qu'on ne pourrais pas faire avec les deux fonctions basiques?
Hors ligne
grum a écrit:
Juste par rapport à ton exemple, pourquoi faire des méthodes statiques ?
Les méthodes statiques sont quatres fois plus rapides que les méthodes "normales"...
Mais en effet... je vois pas l'interet de gagner en performance pour le maintain.inc.php! ;-)
Hors ligne
P@t a écrit:
Mais en effet... je vois pas l'interet de gagner en performance pour le maintain.inc.php! ;-)
Pour ma gouverne, à quoi sert le maintain.inc.php ?
Hors ligne
P@t a écrit:
grum a écrit:
Juste par rapport à ton exemple, pourquoi faire des méthodes statiques ?
Les méthodes statiques sont quatres fois plus rapides que les méthodes "normales"...
Ha pas du tout... Même si ca s'avére exacte!
Les méthodes statiques sont la pour être exécuter sans instancier la classe.
Dans notre cas précis, c'est exactement ce que l'on veut. Ou sinon il faudrait en plus dans le php instancier la classe.
Je suis toujours convaincu qu'il faut faire en objet.
Ca permet d'hériter des toutes les méthodes.
Soit A la classe de base du core piwigo avec les fonctions x1,x2,x3.
Soit B la classe hérité de la classe A de base du thème 1 avec les fonctions y1,y2,y3.
Soit C la classe 1 hérité de la classe B de base du thème 2 hérité tu thème 1 avec les fonctions z1,z2,z3.
Avec les classes, il est facile pour la classe C de réutiliser une fonction de la classe B.
De plus, tosca confirme bien que pour elle, il n'y a de différence entre les 2 copiés/collés à faire.
Comme d'hab, on tourne autour du pot, objet ou sans objet... C'est toujours pareil, toujours la même musique...
On a statué le fait de faire de l'objet de plus en plus pour de ca soit utilisé partout au final... et des qu'on veut en mettre ca coince...
Pour poursuivre la logique du "Attention, c'est trop compliqué pour l'utilisateur", et bien dans ce cas, on ne fait pas de php.
On configure les actions par un ficher XML qui séra interprété.
<theme> <param> <name>MontblancXL</name> <value>toto</value> </param> <param name=MontblancXL value=toto></param> <theme>
Hors ligne
rub a écrit:
De plus, tosca confirme bien que pour elle, il n'y a de différence entre les 2 copiés/collés à faire.
Ctrl-C / Ctrl-V, ça marche tout pareil quel que soit le contenu ;-)
Hors ligne
rub a écrit:
Pour poursuivre la logique du "Attention, c'est trop compliqué pour l'utilisateur", et bien dans ce cas, on ne fait pas de php.
Tout sera toujours trop compliqué tant qu'il n'y aura pas un minimum de doc de référence, qui permette à l'utilisateur - pas complètement débutant quand même - de savoir par quel bout prendre le problème.
A contrario, si les choses sont correctement décrites et expliquées, tout devient plus simple.
Ce n'est pas tel ou tel code qui est complexe, c'est le fait de devoir plonger dans une tonne de sources sans avoir aucun point de repère ... autant chercher une aiguille dans une botte de foin :(
Dernière modification par tosca (2010-04-14 11:06:19)
Hors ligne
Un avantage certain et personne ne pourra me contredire : le fait d'utiliser une classe pour le fichier maintain.inc.php dans un thème ou dans un plugin permettra d'installer/activer/désactiver/supprimer/mettre à jour/bricoler/...er plusieurs thèmes/plugins en une seule opération.
Dernière modification par nicolas (2010-04-14 11:55:07)
Hors ligne
nicolas a écrit:
Un avantage certain et personne ne pourra me contredire ...
Sûrement pas moi en tout cas ... car personne ne m'a encore dit à quoi était censé servir ce fichier, quand il était exécuté et pour quoi faire :/
Hors ligne