🌍
Français
VDigital a écrit:
grum a écrit:
VDigital a écrit:
Les thèmes "héritent" beaucoup les uns des autres
Les thèmes héritent beaucoup les uns les autres, mais n'héritent pas du contenu du répertoire "admin".
Les thèmes c'est l'aspect externe de la galerie que vient faire l'admin alors?
Par contre, les plugins ont besoin d'hériter de fonctions de l'admin, que ceux-ci fonctionnent en admin ou pas.
Mais du moment que tu as des idées... C'est parfait.
depuis la 2.1RC2, les thèmes peuvent disposer d'une interface de configuration en admin (cf. capture). d'ou l'origine de ma remarque..
grum a écrit:
VDigital a écrit:
Les thèmes "héritent" beaucoup les uns des autres
Les thèmes héritent beaucoup les uns les autres, mais n'héritent pas du contenu du répertoire "admin".
Les thèmes c'est l'aspect externe de la galerie que vient faire l'admin alors?
Par contre, les plugins ont besoin d'hériter de fonctions de l'admin, que ceux-ci fonctionnent en admin ou pas.
Mais du moment que tu as des idées... C'est parfait.
tosca a écrit:
grum a écrit:
Pour qui a déjà réalisé un plugin, la signification du "maintain.inc.php" ne se pose même pas ^^; d'où peut-être la raison pour laquelle ta question est passée inaperçue.
1) Je croyais que l'on cherchait justement à attirer des personnes qui n'avaient pas encore touché à ça ...
2) Je n'ai pas pas utilisé ce module en développant mon plugin perso.
3) Je constate que dans le lot de plugins "officiels" installés sur ma galerie, un certain nombre d'entre eux n'ont pas de maintain.inc.php
Tout ça pour dire que la connaissance en question n'est pas forcément bien partagée au sein de la communauté Piwigo en dehors du cercle restreint des développeurs.
1/ oui. sauf que pour faire un thème, il n'est pas indispensable de devoir mettre en place une interface administrateur...
2/ c'est normal. un plugin perso n'est pas un plugin qui exploite tout ce qu'un plugin permet de faire. c'est un palliatif pratique et rapide pour répondre à certains besoins particuliers
3/ c'est qu'il s'agit probablement de plugin ne nécessitant pas une phase d'initialisation lors de l'installation/activation :-D
Quand à la connaissance, c'est clair qu'elle n'est pas parfaitement partagée.
C'est un problème que l'on rencontre aussi en entreprise : partager la connaissance, c'est prendre du temps. Or le temps, il faut en avoir (en entreprise, c'est juste une question de budget)...
Le peu de temps que j'accorde à Piwigo, je l'utilise pour faire des plugins et des thèmes, pas le temps d'en faire plus => n'oublions pas que nous sommes tous des bénévoles !
tosca a écrit:
Tout ça pour dire que la connaissance en question n'est pas forcément bien partagée au sein de la communauté Piwigo en dehors du cercle restreint des développeurs.
Il est vrai que je ne me reconnais plus dans ce problème. Le partage était important. Pourquoi chercher d'un coté à attirer du monde et de l'autre dire "Ha bah la question ne se pose même pas".
M'enfin... :-/
grum a écrit:
Pour qui a déjà réalisé un plugin, la signification du "maintain.inc.php" ne se pose même pas ^^; d'où peut-être la raison pour laquelle ta question est passée inaperçue.
1) Je croyais que l'on cherchait justement à attirer des personnes qui n'avaient pas encore touché à ça ...
2) Je n'ai pas pas utilisé ce module en développant mon plugin perso.
3) Je constate que dans le lot de plugins "officiels" installés sur ma galerie, un certain nombre d'entre eux n'ont pas de maintain.inc.php
Tout ça pour dire que la connaissance en question n'est pas forcément bien partagée au sein de la communauté Piwigo en dehors du cercle restreint des développeurs.
rub a écrit:
Pour sortir de ce débat pas d'autres solutions que d'expérimenter...
On utilise les classes pour les thèmes et les fonctions avec les plugins avec la 2.1.
On voit après 6 mois les retours utilisateurs... et on passe tout en fonctions ou tout en plugins selon les résultats...
euh... çà me semble tard de tout reprendre pour la 2.1.
pour la 2.2 peut-être, mais la 2.1...
VDigital a écrit:
Autant pour les thèmes...
Les thèmes vont prendre un chemin similaire que sera sensé faire l'installation, l'activation, etc. Ce n'est pas notre débat.
On s'interroge simplement sur l'intérêt d'utiliser des classes php pour les thèmes.
Nous sommes d'accord sur l'intérêt des classes du point de vue "développement" en général mais nous ne sommes pas tout à fait convaincus de l'intérêt pour les thèmes.
pour ma part, à moyen terme j'aurais probablement l'utilité du maintain.inc.php, ne t'inquiète pas ;-)
Et mieux vaut l'avoir sans l'utiliser, que de ne pas l'avoir quand on en a besoin !
VDigital a écrit:
Les thèmes "héritent" beaucoup les uns des autres
Les thèmes héritent beaucoup les uns les autres, mais n'héritent pas du contenu du répertoire "admin".
tosca a écrit:
Un grand merci d'avoir pris la peine d'expliquer ;-)
Pour qui a déjà réalisé un plugin, la signification du "maintain.inc.php" ne se pose même pas ^^; d'où peut-être la raison pour laquelle ta question est passée inaperçue.
==> Les derniers sujets partent dans tous les sens, et à chaque fois pour des problèmes de coding lié à l'existencielle question : programmation objet ou non ?.
Un topic dédié existe ;-)
topic:17502
VDigital a écrit:
Autant le maintain.inc.php est clair pour nous en ce qui concerne les plugins...
....
Un grand merci d'avoir pris la peine d'expliquer ;-)
Je trouve dommage qu'il ait fallu attendre la 25è réponse pour qu'un sujet public, traité dans la rubrique "Demandes de fonctionnalité", soit suffisamment décrypté pour que d'autres qu'une poignée de développeurs puisse comprendre un peu de quoi il retourne.
Et même pour les technico-techniciens, ça ne me paraît pas inutile de rappeler le contexte et les enjeux du débat : sauf erreur de ma part, il convient de s'entendre sur des besoins (même techniques) avant de se précipiter sur son clavier pour coder ; avec comme corollaire non négligeable que ce qui est écrit en français a plus de chances d'être compris du commun du mortel que n'importe quel langage qui doit analysé/décompilé au préalable.
(PS pour nicolas : tu pourrais peut-être corriger le lien que tu as donné sur ton post initial, car il ne me paraît pas pointer sur quelque chose de pertinent, ce qui ne facilite pas non plus la prise de connaissance du contexte).
Autant le maintain.inc.php est clair pour nous en ce qui concerne les plugins...
- A l'installation du plugin une fonction permet par exemple de vérifier si les conditions nécessaires et suffisantes pour être activé sont bien remplies.
- A l'activation, une autre fonction permet de créer des tables, les préremplir, ... Bref, faire en sorte que le plugin puisse fonctionner.
- A la désactivation, une autre fonction permet de mener à bien les opérations pour arrêter proprement le plugin sans impacter le reste.
- A la désinstallation, c'est en principe les opérations de nettoyage qui seront réalisées.
Voilà pour les plugins et ceux-ci n'utilisent pas de classe php en théorie pour l'instant.
Autant pour les thèmes...
Les thèmes vont prendre un chemin similaire que sera sensé faire l'installation, l'activation, etc. Ce n'est pas notre débat.
On s'interroge simplement sur l'intérêt d'utiliser des classes php pour les thèmes.
Nous sommes d'accord sur l'intérêt des classes du point de vue "développement" en général mais nous ne sommes pas tout à fait convaincus de l'intérêt pour les thèmes.
Les thèmes "héritent" beaucoup les uns des autres.
Les classes permettraient encore d'augmenter les capacités d'héritage de fonction php.
Bref, nous verrons débarquer les classes, car nous avons décidé d'aller dans ce sens de plus en plus mais nous devons savoir où nous devons arrêter ce principe (au risque de faire des châteaux de cartes avec nos galeries, j'exagère bien entendu).
Et donc, P@t a besoin de nos avis et nous nous exprimons.
;-)
tosca a écrit:
rub a écrit:
tosca a écrit:
1) s'ils sont d'accord sur ce que c'est censé faire
On est d'accord sur ce que c'est censé faire par comment le faire!
Pourquoi aucun d'entre vous ne "se risque" à répondre à ma question ?
Parce que la réponse n'est valable que maintenant à la condtion que P@t n'est pas en train de modifier le code.
Pour le moment il ne fait qu'activer ou désactiver le thème.
L'idée de la classe est de pouvoir ajouter des fonctionnalités sans devoir forcément toucher au thème. Le fait que la classe hérite de la classe mère lui fait bénéficier automatiquement des nouvelles fonctionnalités.
On pourrait imaginer une super méthode changeColor() qui permettrait de modifier les couleurs du thème. Cette méthode magique ajouterait tout ce qu'il faut (html, onglets, css, javascript) automatiquement.
rub a écrit:
tosca a écrit:
1) s'ils sont d'accord sur ce que c'est censé faire
On est d'accord sur ce que c'est censé faire par comment le faire!
Pourquoi aucun d'entre vous ne "se risque" à répondre à ma question ?
rub a écrit:
tosca a écrit:
2) s'ils souhaitent vraiment que d'autres qu'eux y comprennent un jour quelque chose :(
Méchante ;-)
Ou réaliste ? Cf. réponse précédente.
rub a écrit:
A partir de la, ce qu'on fait avec le maintain.inc.php pour l'installation/désinstallation/activation/désactivation pourrait aussi être appliqué (différemment mais en objet) pour le main.inc.php... etc...
Ce qui aide encore moins ceux qui veulent s'y retrouver dans cette jungle ; comprendre que si chacun reste encore une fois dans son coin et fait à sa sauce, comment faire pour avoir des exemples.
:-(
tosca a écrit:
1) s'ils sont d'accord sur ce que c'est censé faire
On est d'accord sur ce que c'est censé faire par comment le faire!
tosca a écrit:
2) s'ils souhaitent vraiment que d'autres qu'eux y comprennent un jour quelque chose :(
Méchante ;-)
tosca a écrit:
rub a écrit:
combien de créateurs vont devoir créer un fichier maintain.inc.php pour leur thème? Car, je présume que celui-ci est facultatif.
Ca doit faire que la 4è fois que je pose la question :
A quoi sert maintain.inc.php ?
Si personne n'est f... de répondre, comment voulez-vous que les créateurs en question aient une petite chance de s'y retrouver !!!
On oublie à chaque fois de répondre car peu importe que ca soit le fichier maintain.inc.php ou toto.inc.php....
Le seul truc à savoir, c'est que c'est un fichier utilisé par un théme/plugin développé par des utilisateurs et utilisés par le coeur de piwigo.
A partir de la, ce qu'on fait avec le maintain.inc.php pour l'installation/désinstallation/activation/désactivation pourrait aussi être appliqué (différemment mais en objet) pour le main.inc.php... etc...
Gotcha a écrit:
Si je dis faux, ça obligera d'autres à venir corriger :-D
Ca serait souhaitable, car je commence sérieusement à me demander :
1) s'ils sont d'accord sur ce que c'est censé faire
2) s'ils souhaitent vraiment que d'autres qu'eux y comprennent un jour quelque chose :(
tosca a écrit:
rub a écrit:
combien de créateurs vont devoir créer un fichier maintain.inc.php pour leur thème? Car, je présume que celui-ci est facultatif.
Ca doit faire que la 4è fois que je pose la question :
A quoi sert maintain.inc.php ?
Si personne n'est f... de répondre, comment voulez-vous que les créateurs en question aient une petite chance de s'y retrouver !!!
Allez, c'est un inculte qui va émettre une hypothèse :
Apparemment, il est utilisé pour définir l'état de quelques fonctions (et de la BDD) à l'activation et à la désactivation du plugin/thème. Par contre, je ne sais pas comment il est appelé.
Si je dis faux, ça obligera d'autres à venir corriger :-D