Piwigo.org

chrisaga · 2006-06-29 19:10:01

Nous avons beaucoup parlé template depuis quelques temps, et j'ai réfléchi aux différentes questions ouvertes sur ce sujet.
Je pense que nous avons bien avancé, en particulier sur la possibilité de créer des templates sans section admin (merci rub pour le coup de main déterminant).
Je pense que nous pouvons encore avancer de façon significative rapidement (c'est à dire avec une première étape en 1.6.0).

Voici les problématiques que j'ai relevées dans le forum et que nous pourrions adresser :

1) Séparation complète des fichiers spécifiques de la section admin,
2) Un template encore plus paramétrable/personalisable afin de reculer l'obligation de recourrir à un nouveau template,
3) Simplifier l'intégration de MOD,
4) Code PHP perso sans "attaquer" le moteur.

Les dernières grosses modifications dans le template vont dans le sens d'une création de fichiers séparés pour des "modules de présentation" utilisés dans les pages :
* le menu
* les miniatures
* le calendrier
* ...

On se retrouve donc avec des jeux de fichiers cohérents composés d'un code php, d'un tpl, et parfois d'une feuille css pour gérer un module ou un sous-module du template.
L'appel de ces fichiers se fait "en dur" dans le code. L'idée est de les mettre en paramètre dans un tableau stocké au niveau du template dans un tpl-default.inc.php qui pourrait être surchargé par un tpl-local.inc.php.
Cela permet de redéfinir un morceau de template et le php qui va avec.
Pour organiser tout ça, on crée une arborescence template-extension parallèle à template qui permet de stocker les extensions aux templates. On peut par exemple traiter ainsi une gestion différente des miniatures comme l'hoverbox de VDigital.
Tant qu'on y est, on déménage dans cette arborescence le sous-répertoire admin.
Ca donnerai :

Code:

|- template
|   |- yoga
|   |   |- *.tpl
|   |   |- *.css
|   |   `- theme
|   `- autre template
|
|- template-extension
|   |- yoga
|   |   |- admin
|   |   |   |- *.tpl
|   |   |   `- *.css
|   |   |- admin.css
|   |   |- admin.tpl
|   |   |- hoverbox.css
|   |   |- hoverbox.php
|   |   |- hoverbox.tpl

On prévoit également de quoi rajouter un peu de code dans le header pour appeler des css pour les bugs des navigateurs.
On ne déplace pas les *.php actuellement dans include (ou pourra le faire à la prochaine version majeure).
Pour la prochaine version, on pourra étudier une vraie interface de type plugin pour appeler ces "modules" (passage de paramètre, fonction call-back, ...) mais pour l'instant l'include de php devrait suffire.

Question est-ce que ça pourrait avoir un impact notable sur les performances ?

rub · 2006-06-29 22:45:35

Je suis plutot +++ pour tous ces changements.

Sympa le coup du template-extension!

Mais pourquoi mettre l'admin dans l'extension?
L'extension est bien une surchage du template de base, alors pourquoi mettre admin dans l'extension?
Il faut le faire que si l'on veut surcharger la partie admin.

Pour les performances, je ne penses pas que ca devrait poser de problèmes, tout dépendra de la surcharge faite et surtout du code php rajouter.

Par contre, il faut que la création d'extension soit simple et guidé. C'est à dire que les tableaux à surcharger devront être bien définis, compréhensibles et regroupés dans un même fichier.
Et un fichier modéle digne ce nom devra être présent dans les sources.
Pourquoi pas ne pas avoir un extention yoga-default, qui sera le fichier exemple mais utlisé par défaut ce qui permettra une mise à jour permanente de celui-ci?

Que veux-tu intégrer dans la 1.6.0?

VDigital · 2006-06-30 00:33:48

Je suis pour bien entendu.

Cependant il y a un truc que je n'ai pas bien saisi...
Comment le traitement d'index.tpl est interrompu pour intégrer hoverbox.tpl (ou autre)?

$template->set_filenames( array('index'=>'index.tpl') );

est très en amont... du pb.

Dans la fonction assign_block_vars() pas propre...
A moins qu'on gère un tableau des "extensions actives" mais quand faire l'appel à l'extension?

A méditer.
8-)

chrisaga · 2006-06-30 09:10:33

VDigital a écrit:
Je suis pour bien entendu.

Cependant il y a un truc que je n'ai pas bien saisi...
Comment le traitement d'index.tpl est interrompu pour intégrer hoverbox.tpl (ou autre)?

J'ai extrait le bloc des vignettes du fichier index.tpl comme je l'avais fait avec le menu (à la demande insistante de certains ;-)
et comme ça avait été fait dès l'origine pour le calendrier et les catégorie (ex subcatify)
On a ainsi un thumbnails.tpl, comme un menubar.tpl, ... qui peuvent-être passés en paramètres au lieu d'être appelés "en dur".
On peut donc appeler hoverbox.tpl à la place de thumbnails.tpl (sans oublier au passage le hoverbox.css).
Je pense que ça peut donner beaucoup de souplesse pour permettre aux "touche à tout" des personalisations ciblées, avec un minimum d'investissement et de modifications de l'existant.
Ça nous permet également d'évalluer les usages et les attentes de nos utilisateurs les plus avertis pour préparer une interface V2 dont on commence à parler.

chrisaga · 2006-06-30 09:20:24

rub a écrit:
Je suis plutot +++ pour tous ces changements.

Sympa le coup du template-extension!

Mais pourquoi mettre l'admin dans l'extension?
L'extension est bien une surchage du template de base, alors pourquoi mettre admin dans l'extension?
Il faut le faire que si l'on veut surcharger la partie admin.

D'accord avec la logique, c'est le compromis que je propose à ceux qui ne le veulent plus dans le template de base :
Pas de template admin séparé pour cause d'éléments communs à doubloner. Un template de base n'a pas d'admin, nous livrons une extension admin.

rub a écrit:
Pour les performances, je ne penses pas que ca devrait poser de problèmes, tout dépendra de la surcharge faite et surtout du code php rajouter.

Juste un tableau et le remplacement des chaines de caractères par les variables du tableau dans le code.

rub a écrit:
Par contre, il faut que la création d'extension soit simple et guidé. C'est à dire que les tableaux à surcharger devront être bien définis, compréhensibles et regroupés dans un même fichier.
Et un fichier modéle digne ce nom devra être présent dans les sources.

Vu que tu as plein d'idées, tu vas m'aider <;o)

rub a écrit:
Pourquoi pas ne pas avoir un extention yoga-default, qui sera le fichier exemple mais utlisé par défaut ce qui permettra une mise à jour permanente de celui-ci?

Peut-être, mais pas dans la 1.6.0 (trop court)

rub a écrit:
Que veux-tu intégrer dans la 1.6.0?

Pas le temps de tout casser et retester, donc intervention minimum - mise en oeuvre du principe, c'est à dire :
1) créer template-extension/yoga
2) déplacer l'admin
3) créer le tableau
4) remplacer les noms en dur dans le code pour les cas où le découpage est déjà bon et où ça a du sens (pas si nombreux que ça)

plg · 2006-07-03 11:16:07

Je suis d'accord pour ces ameliorations. Elles vont dans le sens de mon
objectif final qui est la separation de la partie publique et de la partie
administration. Je trouve un peu "bizarre" de trouver le template
d'administration dans une "extension" de template, mais bon, c'est un mal
pour un bien ;-)

J'aurai trouver plus propre d'avoir un repertoire "template-admin" au meme
niveau que "template" et qu'un template admin puisse utiliser les fichiers
CSS d'un template publique.

Parlons un peu planning. Je compte creer la 1.6.0 ce soir ou demain soir. Et
je suis contre les modifications autres que des corrections de bugs pour les
futures 1.6.x.

Sachant que le cycle de releases candidates est fait pour stabiliser la
release, je suis contre la moindre reorganisation de fichiers entre la
1.6.0RC2 et la 1.6.0.

Chrisaga, considère que maintenant tu bosses pour la 1.7 :-)

Note: On en reparle bientot, mais on s'est loupe sur le planning de la 1.6
en terme de delai, elle aurait du sortir en mars, on est en juillet. Donc,
plus de temps a perdre, et je souhaiterais sortir la 1.7 avant la fin de
l'annee.

nicolas · 2006-07-03 12:32:16

z0rglub a écrit:
J'aurai trouver plus propre d'avoir un repertoire "template-admin" au meme
niveau que "template" et qu'un template admin puisse utiliser les fichiers
CSS d'un template publique.

Tout pareil et c'est ce que j'avais proposé et commité!

rub · 2006-07-03 12:47:03

chrisaga a écrit:
rub a écrit:
Je suis plutot +++ pour tous ces changements.

Sympa le coup du template-extension!

Mais pourquoi mettre l'admin dans l'extension?
L'extension est bien une surchage du template de base, alors pourquoi mettre admin dans l'extension?
Il faut le faire que si l'on veut surcharger la partie admin.
D'accord avec la logique, c'est le compromis que je propose à ceux qui ne le veulent plus dans le template de base :
Pas de template admin séparé pour cause d'éléments communs à doubloner. Un template de base n'a pas d'admin, nous livrons une extension admin.

OK, vu dans ce sens!
Ce qui permettra d'ailleurs de scinder completement la partie admin et public, tout en restant lié!

chrisaga a écrit:
Juste un tableau et le remplacement des chaines de caractères par les variables du tableau dans le code.
rub a écrit:
Par contre, il faut que la création d'extension soit simple et guidé. C'est à dire que les tableaux à surcharger devront être bien définis, compréhensibles et regroupés dans un même fichier.
Et un fichier modéle digne ce nom devra être présent dans les sources.
Vu que tu as plein d'idées, tu vas m'aider <;o)

Pas de soucis ;-)

chrisaga · 2006-07-03 14:08:25

nicolas a écrit:
z0rglub a écrit:
J'aurai trouver plus propre d'avoir un repertoire "template-admin" au meme
niveau que "template" et qu'un template admin puisse utiliser les fichiers
CSS d'un template publique.
Tout pareil et c'est ce que j'avais proposé et commité!

J'ai bien comprise, mais quand on analyse les fichiers, il est évident que la section admin partage un grand nombre d'élémnents avec la section utilisateur et que les fichiers tpl qui définissent les pages d'administration sont loins de se suffire à eux-mêmes.
Franchement on est loins de pourvoir considérer cela comme un template d'admin, même un template d'amin qui réutiliserait des fichiers du template utilisateur.
La solution "template-admin" ne me parraît pas "plus propre" car :
* elle ne correspond pas à la réalité; il n'y a pas de template d'aministration, il y a seulement une partie du template yoga qui sert à gérer la section admin et que l'on a choisi de traiter de façon spécifique (le terme "extension" me semblait convenir, on peut en trouver un autre),
* si l'on gère un template d'admin qui en réalité repose en majorité sur le template de la section utilisateur, on va commencer à gérer des dépendances et la compatibilité entre différentes versions des deux templates.
* elle n'est pas générique et n'empêche pas que la gestion de ce que j'ai appelé des extensions semble pertiente à implémenter puis qu'elle répond au soucis de rendre le template plus adaptable, d'intégrer plus facilement des MODS et d'utiliser du php perso sans intervenir dans le coeur de l'appli. On a ainsi à la fois la séparation entre le php et le html, et celle entre le coeur de l'appli et la présentation dont parlait z0rglub dans un autre topic.

Peut-être que template-extension est mal choisi. On peut essayer template-modules, et y mettre les codes php qui moulinent les variables des fichiers tpl, et qui sont actuellement rangés dans include (comme menubar.inc.php ou category_default.inc.php).

chrisaga · 2006-07-03 18:05:00

z0rglub a écrit:
Je trouve un peu "bizarre" de trouver le template
d'administration dans une "extension" de template, mais bon, c'est un mal
pour un bien ;-)

Justement, ce n'est pas un template d'administration mais la partie du template yoga qui est traite l'administration.

z0rglub a écrit:
Sachant que le cycle de releases candidates est fait pour stabiliser la
release, je suis contre la moindre reorganisation de fichiers entre la
1.6.0RC2 et la 1.6.0.

D'accord avec toi, c'est pourquoi j'avais proposé dans la 1.6.0
de ne pas toucher aux fichiers (sauf éventuellement le sous-répertoire admin qui
semble perturber pas mal de monde) et de ne faire que remplacer les appels "en dur" aux
fichiers tpl (et php associés) par l'évaluation d'une variable dans un tableau de conf, ce
qui permettait aux templateurs de déjà utiliser le mécanisme. On aurait pu déplacer les
fichiers dans une 1.6.x (x>0) voire 1.7 au moment et à la vitesse que l'on veut, et ce sans
impact sur les personalisations réalisées.

z0rglub a écrit:
Chrisaga, considère que maintenant tu bosses pour la 1.7 :-)

Mé heu ...

z0rglub a écrit:
Note: On en reparle bientot, mais on s'est loupe sur le planning de la 1.6
en terme de delai, elle aurait du sortir en mars, on est en juillet. Donc,
plus de temps a perdre, et je souhaiterais sortir la 1.7 avant la fin de
l'annee.

On n'a pas joué le jeu du time-boxing et on a continué a faire de grosses
modifs même sur les RC. Il faut aussi tenir compte du fait que le template a non seulement
ses propres évolutions, mais doit également courrir après celles des autres
<;o)

plg · 2006-07-03 18:23:21

Chrisaga, ce soir, vers 22h maximum, je créé la 1.6.0. D'ici, fais ce que tu penses être raisonnable. Garde le reste pour la 1.7 (et pas pour les 1.6.x, qui ne sont que des versions de correction de bug). Je te fais confiance pour ne pas ajouter de code susceptible d'ajouter des bugs.

Si aujourd'hui on essaie encore d'ajouter plein de petits trucs, c'est parce qu'on n'a pas respecter le mois de mars pour sortie la 1.6.0. Si cela avait été le cas, on aurait déjà bien entâmer les évolutions pour la 1.7 sans toucher à la 1.6. Bref, maintenant on arrête de toucher à la 1.6 sauf correction de bug trivial ou bloquant (mais ce n'est pas le topic pour faire cette communication, je répeterai cela ailleurs)

chrisaga · 2006-07-03 18:50:58

z0rglub a écrit:
Chrisaga, ce soir, vers 22h maximum, je créé la 1.6.0. D'ici, fais ce que tu penses être raisonnable.[...]

Dans ce cas on crée juste le répertoire template-extension/yoga/local
(à moins que quelqu'un ne préfère template-module, mais il faut le dire vite)
et on expliquera aux utilisateurs que s'ils veulent faire des modifs propres et
pérennes, il est préférable de recopier le tpl ou le php à cet endroit et changer
l'appel dans le php kivabien, on les aidera à trouver.
En plus les utilisateurs, quand ils prennent la peine de poser la question dans
le forum, sont souvent soucieux de bien faire.
Même si c'est un peu casse-pied, on aura essayé de préparer les évolutions futures

z0rglub a écrit:
Si aujourd'hui on essaie encore d'ajouter plein de petits trucs, c'est parce qu'on n'a pas respecter le mois de mars pour sortie la 1.6.0. [...]

Tu as raison, il faut savoir s'arrêter, mais de toutes façons, je n'étais pas prêt
non plus. J'avais mes évolutions de template, mais pas la prise en compte des
nouvelles fonctionalités. Il faudrait probablement une autre personne pour
travailler sur les bouts de template correspondant aux nouvelles fonctionalités
pendant que je travaille sur l'ensemble, et inversement.

A ta disposition pour en parler ailleurs

Vive la 1.6.0 !

<:o)

chrisaga · 2006-07-03 20:35:37

chrisaga a écrit:
Dans ce cas on crée juste le répertoire template-extension/yoga/local

Done !

VDigital · 2006-07-04 21:22:25

Chrisaga,

Je viens de lire ton README et je pense qu'on pourrait encore changer d'idées...
L'avenir nous le dira mais cela devrait être
template-extension/yoga/local
et/ou
template-extension/local

Et local ne sert à rien... On pourrait avoir
template-extension/yoga/
et/ou
template-extension/

Si un TPL est dans template-extension, on le prendra dans ce répertoire sauf si le template est yoga et que template-extension/yoga/ existe alors c'est ce TPL qu'il faut parser...

Dirais-je une petite c... ?

8-)

chrisaga · 2006-07-14 16:15:49

Vincent,
merci pour l'agitation d'idées.

On peut toujours changer d'idée, car il n'y a que les imbéciles ...
Ça a d'ailleurs toujours été mon idée <;o)

Quelques réponses sur le reste :

VDigital a écrit:
Si un TPL est dans template-extension, on le prendra dans ce répertoire sauf si le template est yoga et que template-extension/yoga/ existe alors c'est ce TPL qu'il faut parser...

C'est super séduisant, mais j'y vois deux inconvénients :
1) Ça demande un "moulinage" de PWG à chaque affichage, qui me parait peut justifié pour gagner simplement le fait
de renseigner un tableau de variables disant quel code on veut charger. Sur le "moulinage", nous avons une jurisprudence,
à rechercher quelque part dans le forum, où nous avions acté avec z0rglub qu'on évitait de consommer de la cpu inutilement.
Nous pensions bien évidemment aux hébergements partagés, notamment gratuits.
2) Le fait d'utiliser un tableau de variables permet de facilement activer ou désactiver le recours à un code personnalisé,
ou même passer d'un code à un autre, sans avoir à déplacer, ou effacer de fichiers.
3) voir ci dessous pourquoi local sert à quelque chose

VDigital a écrit:
L'avenir nous le dira mais cela devrait être
template-extension/yoga/local
et/ou
template-extension/local

Et local ne sert à rien... On pourrait avoir
template-extension/yoga/
et/ou
template-extension/

Pourquoi "yoga" sert à quelque-chose :
On a pu voir dans les discussions autour du template zen que certains ont une conception complètement différentes du
template : beaucoup moins paramétrable, et beaucoup plus axée code php. C'est un choix différent qui a ses avantages
et vise un autre public de webmasters, donc un choix complémentaire à yoga.
Il y a de fortes chances que les codes proposés pour yoga ne fonctionnenet pas directement avec ces autres templates.

Pourquoi "local" sert à quelque-chose :
local peut être considéré comme un nom par défaut pour un webmaster qui adapte son site.
On peut imaginer que certains souhaitent distribuer leurs extensions (ex l'hoverbox sur laquelle tu as travaillé) et qu'un
webmaster souhaite en tester plusieurs.
Le fait de ne pas tout mélanger dans un dossier local commun me semble une bonne pratique pour conserver la maintenabilité d'un site.
Sur cette base, on peut imaginer dans l'avenir des templates avec des extensions activables ou désactivables à volonté,
soit directement par le profil utilisateur, mais ça demande des modifications de PWG, soit plus simplement par le biais du
choix du thème via le themeconf.inc.php

Continuons le débat ...

<:o)

Piwigo.org

Annonce

#1 2006-06-29 19:10:01

[Template] encore un peu de rangement ?

Code:

#2 2006-06-29 22:45:35

Re: [Template] encore un peu de rangement ?

#3 2006-06-30 00:33:48

Re: [Template] encore un peu de rangement ?

#4 2006-06-30 09:10:33

Re: [Template] encore un peu de rangement ?

VDigital a écrit:

#5 2006-06-30 09:20:24

Re: [Template] encore un peu de rangement ?

rub a écrit:

rub a écrit:

rub a écrit:

rub a écrit:

rub a écrit:

#6 2006-07-03 11:16:07

Re: [Template] encore un peu de rangement ?

#7 2006-07-03 12:32:16

Re: [Template] encore un peu de rangement ?

z0rglub a écrit:

#8 2006-07-03 12:47:03

Re: [Template] encore un peu de rangement ?

chrisaga a écrit:

rub a écrit:

chrisaga a écrit:

rub a écrit:

#9 2006-07-03 14:08:25

Re: [Template] encore un peu de rangement ?

nicolas a écrit:

z0rglub a écrit:

#10 2006-07-03 18:05:00

Re: [Template] encore un peu de rangement ?

z0rglub a écrit:

z0rglub a écrit:

z0rglub a écrit:

z0rglub a écrit:

#11 2006-07-03 18:23:21

Re: [Template] encore un peu de rangement ?

#12 2006-07-03 18:50:58

Re: [Template] encore un peu de rangement ?

z0rglub a écrit:

z0rglub a écrit:

#13 2006-07-03 20:35:37

Re: [Template] encore un peu de rangement ?

chrisaga a écrit:

#14 2006-07-04 21:22:25

Re: [Template] encore un peu de rangement ?

#15 2006-07-14 16:15:49

Re: [Template] encore un peu de rangement ?

VDigital a écrit:

VDigital a écrit:

Pied de page des forums