nicolas a écrit:

Un avantage certain et personne ne pourra me contredire ...

Visiblement ce n'est pas évident pour tout le monde mais par construction, c'est un fait.
Donc tu as raison, il nous faut des classes pour les maintain.inc des plugins (Cf. besoins de grum).



Si j'en reviens aux thèmes par contre, cela ne semble pas indispensable. Pour simplifier la vie des designers, il vaudrait mieux les éviter.

Peut-on imaginer que les 2 solutions "cohabitent" pour les thèmes ???

Je veux dire des thèmes simples sans classes, pour les débutants qui ne supporteront pas l'héritage des fonctions...
Et des thèmes avec des classes de maintenance qui permettront l'empilage des activations / configurations multiples (quoique pour moi je n'en perçoit pas encore l'intérêt, j'ai l'impression qu'on s'engage dans une usine à gaz (contrairement aux plugins j'insiste)).

Quid des désinstallations de parents vis-à-vis des thèmes/plugins enfants...?

(Je raconte peut-être un tas de bêtises).

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 !!!

Dernière modification par tosca (2010-04-14 14:27:55)

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:

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 ;-)

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.

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.
;-)

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 ;-)
[Forum, topic 17502] de l'usage de la programmation objet et autres

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... :-/