🌍
Français
flipflip a écrit:
Ok, merci pour ces précision. Donc pour le moment on continue comme avant ?
Oui, tant que l'on n'a pas mieux précisé ce qu'on veut faire, mais on peut essayer de "tendre vers..."
Ok, merci pour ces précision. Donc pour le moment on continue comme avant ?
flipflip a écrit:
Salut, j'ai enfin pris le temps de lire la totalité du post... ouf dur dur.
J'ai pas tout compris. Enfin si, j'ai pigé pour la partie tpl, mais qu'en est-il des fichiers php. Par exemple je suis en train d'adapter Download Multi à la 1.6.1 et j'ai besoins de modifier le fichier category_default.inc.php. Il a été évoqué, dans ce post, la possibilité de surcharger les fichiers contenue dans include/ mais j'ai pas compris comment ça marche.
Comme pour les tpl, je proposais de les mettre dans une table de configuration, et de de plus faire les include "en dur" mais d'utiliser la table.
Comme on met les fichiers dans "template-extension", ils ne sont pas écrasés par la mise à jour.
Si après une mise à jour une extension ne fonctionne plus, il suffit de supprimer l'appel aux fichiers (tpl, php, ...) modifiés pourrevenir à un fonctionnemeent standard.
Pour que ce soit possible, il faut encore dans certains cas séparer le php "qui produit" du php "qui présente" (ex: les tags)
Ce n'est pas encore des specs, mais un début d'idée pour rendre les templates plus modulaires, mieux séparer la partie "production" de la partie "présentation" et donc intégrer plus facilement des MOD.
<:o)
Salut, j'ai enfin pris le temps de lire la totalité du post... ouf dur dur.
J'ai pas tout compris. Enfin si, j'ai pigé pour la partie tpl, mais qu'en est-il des fichiers php. Par exemple je suis en train d'adapter Download Multi à la 1.6.1 et j'ai besoins de modifier le fichier category_default.inc.php. Il a été évoqué, dans ce post, la possibilité de surcharger les fichiers contenue dans include/ mais j'ai pas compris comment ça marche.
VDigital a écrit:
On le voit dans le discours de jillij.
Il râle parce que l'indépendence PWG et template n'est pas assurée.
Lui même ne se préoccupe pas de ce que donne Video Integrator sur son template (et je ne lui reproche pas).
OK, mais soyons sérieux, on a encore du chemein avant d'atteindre une indépendance, qui de toutes façons ne sera jamais complète.
Ceci dit, je suis pour la favoriser le plus possible.
VDigital a écrit:
D'où je dis, on donne la boite template-extension.
Mais on ne gère pas le contenu... pas de notion /local/
C'est l'équivalent de /modules/ dont on avait parlé... il y a ... MOD_Modules : Ajouter des modules à PWG
Plus clair? Pas sûr ...
8-)
Je pense que c'est plus clair. Mon propos n'était pas de remplir la boîte mais de proposer une façon de la ranger dans le but, entre
autres, de faciliter le support.
Mais sur ce dernier point, tu es plus concerné que moi <;o)
Mon message précedent et l'autre sujet concernant le regroupement vont dans le même sens.
chrisaga a écrit:
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.
Je suis d'accord. 8-)
Quand je dis:
template-extension/local
local ne sert à rien... On pourrait avoir
template-extension/
C'est simple, je me refuse à imaginer qu'on cherche à assurer la compatibilité à tout prix des extensions avec les adaptations locales.
C'est simple... Donc, j'explique.
Ce qui suit est une fiction:
Rub décide d'utliser un futur hoverbox, mais il le modifie pour que la miniature apparaise dans une loupe.
Hoverbox est dans template-extension... Ok pas de débat, je n'ai pas encore tout à fait pigé mais je te fait confiance.
La loupe n'est pas hoverbox.
Ce n'est pas à Rub à être impacter par les changements de version de PWG.
Par contre si hoverbox évolue et propose une vue kaleidoscopique...
Les modifs de la loupe de Rub sont impactés.
Pour l'équipe PWG, on doit penser à éviter des conséquences (ne pas à avoir à réinstaller hoverbox) en cas de changement de PWG.
Mais l'équipe de PWG, n'a pas à se préoccuper des Locales de Hoverbox. C'est soit à l'auteur d'Hoverbox.
Soit s'il ne s'en préoccupe pas, le webmaster lui même.
On le voit dans le discours de jillij.
Il râle parce que l'indépendence PWG et template n'est pas assurée.
Lui même ne se préoccupe pas de ce que donne Video Integrator sur son template (et je ne lui reproche pas).
D'où je dis, on donne la boite template-extension.
Mais on ne gère pas le contenu... pas de notion /local/
C'est l'équivalent de /modules/ dont on avait parlé... il y a ... MOD_Modules : Ajouter des modules à PWG
Plus clair? Pas sûr ...
8-)
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)
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 a écrit:
Dans ce cas on crée juste le répertoire template-extension/yoga/local
Done !
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, 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)
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)
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 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 ;-)
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é!