Piwigo.org

grum · 2010-04-14 00:05:41

suite [Forum, post 139897 by P@t in topic 17483] [2.1RC1] premieres impressions qui commence à partir dans tous les sens...

P@t a écrit:
grum a écrit:
Et je n'ai pas attendu le débat :
- tous mes plugins exploitent des classes communes (dans GrumPluginClasses, il y a "classes" ;-)) qui leurs offrent des fonctionnalités de base sur l'intégration dans Piwigo
- suite à la nouveauté offerte de disposer d'une interface pour les thèmes, j'ai créé une classes pour les miens (j'ai hésité à exploiter GrumPluginClasse, mais je me suis dit que çà pouvait être compliqué d'imposer çà juste pour un thème)
C'est super coté développeur, par contre coté utilisateur, je n'aime pas du tout cette façon de faire... En tant qu'utilisateur lambda, quand je souhaite installer un plugin sur un programme, je déteste voir un message affichant "ce plugin necessite tel autre plugin pour fonctionner". J'aime quand tout est simple et automatique... pour preuve le plugins manager et piwigo auto upgrade! Quand GrumPluginsClasses s'installera de manière complètement transparente, je changerai peut-etre de point de vue ;-))
En plus coté performances, c'est pas non plus le top de charger un paquet de fonctions dont la plupart ne serviront pas au plugin...

c'est clair que je devrais mettre en place un système d'installation automatique de GrumPluginClasses lors de l'installation de l'un de mes plugins.
Mais :
1/ j'ai la flemme
2/ j'ai la flemme
3/ un utilisateur qui est réellement intéressé par les plugins que je propose est tout à fait capable de prendre l'initiative d'installer ce qu'il faut avant
4/ je pars du principe que c'est à Piwigo de fournir le framework permettant de gérer les éventuelles dépendances entres plugins (je pourrais m'affecter cette tache, mais idem que les points 1 et 2, avec en plus pour l'instant un manque de temps flagrant)

Quand au côté performances, ce n'est pas parce qu'un fichier est installé sur le disque qu'il est chargé en mémoire. Si quelque chose est chargé en mémoire, c'est parce qu'il y en a besoin.
Si quelque chose est proposé dans GPC, c'est qu'il y a au moins un de mes plugins qui l'exploite.

A l'inverse, je te dirais que ce n'est pas top d'avoir 36 programmes différents qui font tous la même chose :
- en terme de maintenance c'est l'horreur
- en terme de performance, tu ne gagne pas forcément beaucoup

P@t a écrit:
Pour en revenir à la classe pour le maintain.inc.php d'un thème, je ne suis toujours pas emballé, vu que personne ne m'a encore apporté un exemple de l'utilité d'une telle classe...
Je répète qu'un créateur de thème n'est pas forcément callé en php: je me revois deux ans en arrière à mes début en programmation, je ne comprenais scritement rien au classes, et quand j'en voyais une, je préférais passer mon chemin... les choses ont changées bien sur, mais ne repoussons pas les développeurs de thèmes avec des choses compliquées et inutiles. Je rapelle qu'un des objectifs de ce nouveau système de thèmes/templates est d'augmenter le nombre de contributions!

Pour ma part, j'ai fini de coder l'interface d'admin de mon thème Gally.

En synthèse, j'ai codé 4 templates et 2 classes, mais je n'ai pas utilisé le fichier maintain.inc.php. pour l'instant.
Ce que nous a proposé P@t est super, et je compte bien l'exploiter un maximum (P@t qui a vu "le code" mon thème comprends ce que je veux dire par là) et être en mesure d'initialiser certaines choses à l'installation ou désinstallation du thème m'intéresse au plus au point.

Après cf. [Forum, post 139923 by grum in topic 17500] 36 manières de looker votre piwigo, la réalisation d'un thème peut se faire à plusieurs niveau. Pour ma part je suis dans le dernier ^_^; et je ne vois pas pourquoi je devrais être bridé parce qu'un créateur de thème n'y connait pas forcément grand chose en PHP : l'exploitation des possibilités offertes pour l'interface d'administration n'est pas obligatoire pour créer un thème.

Quand aux classes, c'est bien simple.
J'ai 3 thèmes pour Gally, tous basés sur Gally-default.

Les trois thèmes disposent pour l'instant de la même interface.

Pour le thème Gally/Lapis-Lazuli par exemple, le fichier admin.inc.php contient 2 lignes de code :

Code:

include_once(PHPWG_THEMES_PATH.'gally-default/admin/GallyDefault.class.inc.php');
$interface = new GallyDefault("Gally/Lapis-lazuli", "", PHPWG_THEMES_PATH.'gally-lapis-lazuli/conf');

Ces deux lignes de codes permettent de gérer l'interface "standard".

Maintenant si je veux par exemple rajouter un 4ème onglet de configuration juste pour ce thème (Gally dispose de 3 onglet de configuration), je dérive ma classe

Code:

include_once(PHPWG_THEMES_PATH.'gally-default/admin/GallyDefault.class.inc.php');

class GallyLapisLazuli extends GallyDefault 
{
  public function initTabSheet()
  {
   parent::initTabSheet()
   $this->tabsheet->add(
     'tab_name',
     l10n('my new tabsheet'),
     $this->getAdminThemeLink().'&amp;fGally_tabsheet=the_new_tabsheet');
 }
}

$interface = new GallyLapisLazuli("Gally/Lapis-lazuli", "", PHPWG_THEMES_PATH.'gally-lapis-lazuli/conf');

je créé juste un nouveau template "the_new_tabsheet.tpl" dans le répertoire admin, lequel contient la maquette du contenu du nouvel on,glet, et pouf j'ai une nouvelle page sur l'interface, sur laquelle la prise en compte des options (lecture & mise à jour) est déjà gérée par la classe.

Si l'interface du thème par défaut évolue (ajout d'un 4ème onglet sur l'interface par défaut) alors le thème Gally/Lapis-Lazuli évolue automatiquement sans que je n'ai quoi que ce soir à coder : l'onglet ajouté se trouvera être un 5ème onglet complémentaire aux 4 premiers par défaut.

Pour ma part, je trouve çà bien plus simple que de reprendre des tonnes de lignes de codes à maintenir partout... Après, je n'irais forcer personne à utiliser la programmation objet.

En comparaison je suppose que te son côté, pour le thème Sobre, Gotcha as recopié le code de montblancxl. Si montblancxl évolue, il lui faudra reprendre le code en question...

tosca · 2010-04-14 00:23:35

grum a écrit:
3/ un utilisateur qui est réellement intéressé par les plugins que je propose est tout à fait capable de prendre l'initiative d'installer ce qu'il faut avant

C'est effectivement pas la mer à boire ...

grum a écrit:
4/ je pars du principe que c'est à Piwigo de fournir le framework permettant de gérer les éventuelles dépendances entres plugins

+1
C'est d'ailleurs bien ce qu'on met en place pour les thèmes, non ?

P@t a écrit:
Je répète qu'un créateur de thème n'est pas forcément callé en php: je me revois deux ans en arrière à mes début en programmation, je ne comprenais scritement rien au classes, et quand j'en voyais une, je préférais passer mon chemin...

Je ne trouve pas forcément plus simple de passer par du php "traditionnel", et je suis toujours estomaquée de voir que l'on renvoie régulièrement les forumistes vers la doc Smarty !

POO ou pas, il faut de toute manière commencer par s'y retrouver dans la jungle des programmes sources, variables, fonctions, etc. Piwigo pour laquelle il n'y a quasiment aucune documentation.

Pour pouvoir "rentrer" dans le code, à peu près n'importe qui de "non chevronné" devra donc s'appuyer sur le support assuré par les "techniciens" du forum ... qui devraient être en mesure de "piloter" les premiers pas quel que soit le mode de programmation retenu.

Dernière modification par tosca (2010-04-14 00:26:11)

grum · 2010-04-14 00:29:59

tosca a écrit:
je suis toujours estomaquée de voir que l'on renvoie régulièrement les forumistes vers la doc Smarty !

pour ma part, je ne bosse pas sur des templates sans avoir un onglet ouvert pointant sur la doc Smarty !!
tout comme je ne code pas de PHP sans un onglet ouvert sur la doc PHP.
de même pour le HTML, le modèle DOM et jQuery...

bref, si on renvoit vers une documentation, c'est peut-être aussi parce que sans la documentation on ne sait tout pas faire ;-)
et si Piwigo exploite diverses technologies pour exister, ce n'est pas à Piwigo d'expliquer comment ces technologies fonctionnent... si ??

tosca · 2010-04-14 00:40:12

grum a écrit:
pour ma part, je ne bosse pas sur des templates sans avoir un onglet ouvert pointant sur la doc Smarty !!
tout comme je ne code pas de PHP sans un onglet ouvert sur la doc PHP.
de même pour le HTML, le modèle DOM et jQuery...

bref, si on renvoit vers une documentation, c'est peut-être aussi parce que sans la documentation on ne sait tout pas faire ;-)
et si Piwigo exploite diverses technologies pour exister, ce n'est pas à Piwigo d'expliquer comment ces technologies fonctionnent... si ??

Je suis bien d'accord, j'ai moi aussi toujours un certain nombre d'onglets ouverts et de sites que je consulte régulièrement lorsque je code.

Mais je trouve très réducteur de dire qu'il suffit de plonger dans les docs des outils pour pouvoir intervenir dans Piwigo d'un coup de baguette magique !

P@t · 2010-04-14 01:12:58

grum a écrit:
3/ un utilisateur qui est réellement intéressé par les plugins que je propose est tout à fait capable de prendre l'initiative d'installer ce qu'il faut avant

Bien sur, mais moi, en tant qu'utilisateur, ca m'agace (question de flemme aussi!)

grum a écrit:
4/ je pars du principe que c'est à Piwigo de fournir le framework permettant de gérer les éventuelles dépendances entres plugins (je pourrais m'affecter cette tache, mais idem que les points 1 et 2, avec en plus pour l'instant un manque de temps flagrant)

En fait, j'osais pas te le proposer ;-)
Plus sérieusement, pierrick compte faire ca pour les thèmes... pourquoi pas pour les plugins.
J'avais eu l'idée d'ajouter la fonctionnalité à PEM: "Required extension".
Pour un thème ou un plugin, on peut sélectionner une ou plusieurs extensions requises qui s'installeront automatiquement dans piwigo...
Si l'envie de dit de faire évoluer les plugins de piwigo dans ce sens, je m'occuperai volontier de la partie PEM!

grum a écrit:
Après cf. [Forum, post 139923 by grum in topic 17500] 36 manières de looker votre piwigo, la réalisation d'un thème peut se faire à plusieurs niveau. Pour ma part je suis dans le dernier ^_^; et je ne vois pas pourquoi je devrais être bridé parce qu'un créateur de thème n'y connait pas forcément grand chose en PHP : l'exploitation des possibilités offertes pour l'interface d'administration n'est pas obligatoire pour créer un thème.

Je vois que finalement le "simple" admin.inc.php te permet de faire exactement ce que tu veux en deux lignes!
Y a-t-il vraiment besoin de compliquer le maintain.inc.php? La struture actuelle te bride-t-elle pour l'installation de tes thèmes? ;-)

grum a écrit:
Quand aux classes, c'est bien simple.
J'ai 3 thèmes pour Gally, tous basés sur Gally-default.

Les trois thèmes disposent pour l'instant de la même interface.

La classe est bien pratique ici...
Et ca me gène beaucoup moins que pour GPC, puisque c'est intégré au thème par défaut!

grum a écrit:
En comparaison je suppose que te son côté, pour le thème Sobre, Gotcha as recopié le code de montblancxl. Si montblancxl évolue, il lui faudra reprendre le code en question...

Vu la simplicité de l'interface de Montblanc XL, ca ne me parait pas etre un problème!
Et puis Sobre n'a rien à voir avec MontblancXL, pourquoi utiliserait-il une classe de MontblancXL???

vincent3569 · 2010-04-14 08:56:22

grum a écrit:
tosca a écrit:
je suis toujours estomaquée de voir que l'on renvoie régulièrement les forumistes vers la doc Smarty !
pour ma part, je ne bosse pas sur des templates sans avoir un onglet ouvert pointant sur la doc Smarty !!
tout comme je ne code pas de PHP sans un onglet ouvert sur la doc PHP.
de même pour le HTML, le modèle DOM et jQuery...

bref, si on renvoit vers une documentation, c'est peut-être aussi parce que sans la documentation on ne sait tout pas faire ;-)
et si Piwigo exploite diverses technologies pour exister, ce n'est pas à Piwigo d'expliquer comment ces technologies fonctionnent... si ??

le problème n'est pas de renvoyer vers le support des outils fondamentaux, mais d'avoir une doc assez indigeante sur le framework Piwigo.
je suis certainement assez lourd (et je m'en excuse) en comparant souvent Piwigo et ZenPhoto, mais regardez un peu ces liens :

http://www.zenphoto.org/category/User-Guide/
http://www.zenphoto.org/documentation/elementindex.html

toute la doc nécessaire est générée (on peut discuter sur le niveau d'information de certaines fonctions...), ce qui permet à chaque utilisateurs d'avoir les infos nécessaires pour développer un thème et pour le coup, il y a pléthore de fonctions qui permettent d'avoir une charte graphique vraiment personnalisée et non pas dérivée de modèles standards.

le wiki est bien utile pour cela, mais je le vois souvent comme une compilation de "how to do", mais pas comme une référence documentaire.
au final, les utilisateurs basiques que je suis, sont dans l'incapacité des faire quoi que ce soit sans votre aide (et vous n'êtes pas avare, heureusement).

dernier exemple en date : sur mon thème, j'avais supprimé la barre de navigation sur la page picture et je n'avais plus de navigation au clavier.
il a fallu un certain nombre de post de la part de différents membre de l'équipe avant qu'on trouve la source de mon problème...
à ma connaissance, le lien entre barre de navigation et navigation au clavier n'est décit nulle part.

tosca · 2010-04-14 09:05:38

vincent3569 a écrit:
le problème n'est pas de renvoyer vers le support des outils fondamentaux, mais d'avoir une doc assez indigeante sur le framework Piwigo.

+1

vincent3569 a écrit:
le wiki est bien utile pour cela, mais je le vois souvent comme une compilation de "how to do", mais pas comme une référence documentaire.

+++
Un tutoriel ne remplacera jamais une documentation de référence, même succincte !

vincent3569 a écrit:
au final, les utilisateurs basiques que je suis, sont dans l'incapacité des faire quoi que ce soit sans votre aide

... et restent dépendants du support des "techniciens" sauf à vouloir/pouvoir faire un investissement personnel considérable sur Piwigo.

Gotcha · 2010-04-14 10:50:36

P@t a écrit:
grum a écrit:
En comparaison je suppose que te son côté, pour le thème Sobre, Gotcha as recopié le code de montblancxl. Si montblancxl évolue, il lui faudra reprendre le code en question...
Vu la simplicité de l'interface de Montblanc XL, ca ne me parait pas etre un problème!
Et puis Sobre n'a rien à voir avec MontblancXL, pourquoi utiliserait-il une classe de MontblancXL???

Oui c'est vrai, j'ai plus que copié en repérant de manière visuel (donc vraiment sans rien comprendre à ce que je faisais !) ce qui se faisait du coté de MontblancXL. Pour autant, j'ai déjà envie de changer quelques trucs (CF : [Forum, post 139898 by Gotcha in topic 17488] [Thème] Sobre).

Une documentation comme celle de ZenPhoto (merci Vincent3569) c'est bien... ça va aider... mais... il n'en reste pas moins obligatoire de connaître les base du langage.
Et quand je vous lit en train de discuter sur POO et autres classes, personnelement j'attends simplement que ça se décante pour ensuite n'avoir qu'une seule ligne de -//:---\spam à suivre.

Comprenez que lire/écrire/comprendre tout ce que vous racontez au niveau technique, ça me passe à 1000 lieux de la tête. La documentation technique sera de toutes manière trop technique pour Mr Tout- Lemonde et pas assez pour Mr Geecker.
Je préfère largement un "how to" qui met sur la voix et ensuite, sur cette base de cas concret (cas d'école dira t-on) on verra se qu'il faut adapter.
Donner de la documentation sans en donner les bases c'est le travail à l'envers. Et comme les bases sont extérieurs à Piwigo, il est normal de renvoyer vers la documentation spécifique.

En revanche, je ne nie pas qu'un documentation sur les truc et les machins pour développeurs Piwigo, ca sera un plus indéniable. Mais ne comptez pas faire quelque chose d'ouvert à n'importe qui avec une telle documentation. Rien que le wiki de base est incompris, alors une doc technique...

Bref, tout ça pour dire que l'orientation et les recommandations c'est à l'équipe de la définir (chose qui en court de débat, c'est déjà ça) mais que par la suite il faudra faire une synthèse.
Trop souvent on passe des kilomètres de blabla et ... rien. Soit ça n'aboutit pas (dans ce cas pas la peine d'en rajouter lol) soit le fruit du débat est noyer et réservé à quelques privilégié.

Alors une petite synthèse pour résumer de la direction prise à la suite d'un débat, tout le monde retourne dans son petit coin et recommence à travailler en solo.

:-(

rub · 2010-04-14 10:57:34

P@t a écrit:
grum a écrit:
4/ je pars du principe que c'est à Piwigo de fournir le framework permettant de gérer les éventuelles dépendances entres plugins (je pourrais m'affecter cette tache, mais idem que les points 1 et 2, avec en plus pour l'instant un manque de temps flagrant)
En fait, j'osais pas te le proposer ;-)
Plus sérieusement, pierrick compte faire ca pour les thèmes... pourquoi pas pour les plugins.
J'avais eu l'idée d'ajouter la fonctionnalité à PEM: "Required extension".
Pour un thème ou un plugin, on peut sélectionner une ou plusieurs extensions requises qui s'installeront automatiquement dans piwigo...
Si l'envie de dit de faire évoluer les plugins de piwigo dans ce sens, je m'occuperai volontier de la partie PEM!

+1 bien entendu

tosca · 2010-04-14 11:15:33

Gotcha a écrit:
Je préfère largement un "how to" qui met sur la voix

ET

Gotcha a écrit:
Rien que le wiki de base est incompris

Y a peut-être un malaise ...

Gotcha a écrit:
Donner de la documentation sans en donner les bases c'est le travail à l'envers. Et comme les bases sont extérieurs à Piwigo, il est normal de renvoyer vers la documentation spécifique.

On peut aussi renvoyer vers le dictionnaire pour ceux qui ne comprennent pas le français ...

A ce que je sache, personne ne nie l'utilité des manuels et autres documentation sur les différents langages et outils utilisés.
L'enjeu ici est bien une documentation PIWIGO.

Gotcha a écrit:
Alors une petite synthèse pour résumer de la direction prise à la suite d'un débat, tout le monde retourne dans son petit coin et recommence à travailler en solo.

Je ne trouve pas que de travailler chacun dans son coin selon ses propres idées/convictions soit la meilleure des méthodes pour développer en commun :/

vincent3569 · 2010-04-14 12:22:00

Gotcha a écrit:
Une documentation comme celle de ZenPhoto (merci Vincent3569) c'est bien... ça va aider... mais... il n'en reste pas moins obligatoire de connaître les base du langage.

je n'ai pas dit le contraire.
je dis simplement que le framework Piwigo n'est pas (suffisement) documenté pour les utilisateurs (certainement experts).

si une doc PIWIGO documente une méthode du genre genererPagination(nombre de vigentte par page, monter suiv/prec, monter permier/dernier, navigation sur les liens suiv/prec,premier/dernier, nombre de page affichée), cela permet à un webdesigner de connaitre et comprendre la fonction de niveau framework et comment l'utiliser dans un tpl.
cela ne le dispense pas de connaitre au préalable le fonctionnement et la syntaxe d'une boucle while {} pour afficher les vignettes.

sans cette doc, Piwigo reste sur un modèle trop "fermé".

c'est un peu HS par rapport au sujet de la POO, mais c'est un point qu'il ne faut pas perdre de vue.
Il y a peut-être plein de Luciano Amodio qui voudrait faire du webdesign avancé avec PIWIGO mais qui ne peuvent pas pour les raisons expliquées ici.

Dernière modification par vincent3569 (2010-04-14 12:23:40)

Piwigo.org

Annonce

#1 2010-04-14 00:05:41

de l'usage de la programmation objet et autres

P@t a écrit:

grum a écrit:

P@t a écrit:

Code:

Code:

#2 2010-04-14 00:23:35

Re: de l'usage de la programmation objet et autres

grum a écrit:

grum a écrit:

P@t a écrit:

#3 2010-04-14 00:29:59

Re: de l'usage de la programmation objet et autres

tosca a écrit:

#4 2010-04-14 00:40:12

Re: de l'usage de la programmation objet et autres

grum a écrit:

#5 2010-04-14 01:12:58

Re: de l'usage de la programmation objet et autres

grum a écrit:

grum a écrit:

grum a écrit:

grum a écrit:

grum a écrit:

#6 2010-04-14 08:56:22

Re: de l'usage de la programmation objet et autres

grum a écrit:

tosca a écrit:

#7 2010-04-14 09:05:38

Re: de l'usage de la programmation objet et autres

vincent3569 a écrit:

vincent3569 a écrit:

vincent3569 a écrit:

#8 2010-04-14 10:50:36

Re: de l'usage de la programmation objet et autres

P@t a écrit:

grum a écrit:

#9 2010-04-14 10:57:34

Re: de l'usage de la programmation objet et autres

P@t a écrit:

grum a écrit:

#10 2010-04-14 11:15:33

Re: de l'usage de la programmation objet et autres

Gotcha a écrit:

Gotcha a écrit:

Gotcha a écrit:

Gotcha a écrit:

#11 2010-04-14 12:22:00

Re: de l'usage de la programmation objet et autres

Gotcha a écrit:

Pied de page des forums