🌍
Français
J'essaye d'adresser cette question dans le topic 7722
rub a écrit:
Donc pour reprendre le point précédent, plutot que de séparer les css et les tpl, ne pourrait-on pas séparer encore plus les thèmes et les templates.
Attention à ne pas trop charger le thème non plus, mais on pourrait effectivement mettre moins d'éléments de présentation dans le template.
Je redis quand même qu'il faut que les thèmes restent faciles à comprendre et adapter.
La surcharge permet de toutes façons aux spécialistes de tout redéfinir.
rub a écrit:
Pour qu'un théme soit utilisable sur n'importe quel template?
On en a déjà discuté.
C'était même mon idée de départ, mais on a fini par admettre que dans la plupart des cas les templates seront suffisament différents pour que l'on ne puisse pas utiliser le même thème.
Quand on voit les discussions actuelles (template zen, etc.) on peut se dire que ce n'est pas faux.
Certains contestent même les paramétrages dans template-common.
Mais ça, je pense qu'on garde car même si ça sera inutile pour certains templates, d'autres pourront en bénéficier.
rub a écrit:
Justement avec les ID et les class quels sont les possibilités offertes? (Cachés des zones des textes par exemple, les couleurs, la disposition, ...) ( le css est moi ca fait 2 pour le moment)
Les class permettent de fixer une règle pour une classed'éléments HTML (affichage ou non, couleur, etc.)
Les Id font la même chose pour un seul élément. On peut cumuler.
rub a écrit:
Et de la configuration/paramétrage/personnalisation avec des fichiers php?
On a déjà un début dans les thèmes avec themeconf.inc.php
On peut essayer d'aller plus loin.
pfrize a écrit:
[
1. Le style stricto sensu :
2. La disposition, ou "layout", de la page :
3. Les éléments conditionnels ou non-standards de la page :
Plutot d'accord sur les 3 points aussi!
chrisaga a écrit:
rub a écrit:
En fait, je me demande si ca ne serait pas plus simple de faire un nouveau template simplement en modifiant les css et sans touché aux tpl. Du moins faire quelque chose, qui permettent de gérer les 90% des nouveaux templates.
Excellent ! ce que tu décrit, c'est toute la notion de thème qui a été séparée du reste du template dans la version 1.6 justement pour ça.
Un thème, ce n'est pas que des couleurs (Cf. hk-3 pour yoga)
Oui, oui, mais je penses que la 1.6.0 n'est qu'une première étape et qu'on peut faire mieux!
Ce qui m'interroge c'est la localisation des thémes! Pourquoi les mettre avec un template alors qu'il pourrait être utliser par un autre template! (D'ailleurs, est-ce que ca posera des problèmes?)
chrisaga a écrit:
rub a écrit:
Pourquoi, ne pas séparer complementement les fichiers tpl et les fichiers css!
En fait, ça ne simplifie rien.
Les css qui sont laissée dans le template servent à deux choses :
- structurer les éléments de base (formulaires, inputs, icones en toolbar, ...)
- donner une structure de base au template.
Ces règles peuvent être surchargées par le thème si nécessaire.
Ok, j'avais pas pigé totalement à quoi servés les autres css.
Donc pour reprendre le point précédent, plutot que de séparer les css et les tpl, ne pourrait-on pas séparer encore plus les thèmes et les templates.
Pour qu'un théme soit utilisable sur n'importe quel template?
On aurait la même arbo que proposé au début du sujet mais dans structure on aurait des tpl et des css.
Ce qui pourrait faire:
---template
+---structure (tpl, css, php)
+---struct1
+---struct2
+---theme (tpl, css, php)
+---yoga (style 1)
+---style_2
chrisaga a écrit:
Nous pouvons encore améliorer tout ça, et surtout, tu as raison prévoir dès le début les id et les classes nécessaires, et éviter de les changer d'une version à l'autre.
Justement avec les ID et les class quels sont les possibilités offertes? (Cachés des zones des textes par exemple, les couleurs, la disposition, ...) ( le css est moi ca fait 2 pour le moment)
Et de la configuration/paramétrage/personnalisation avec des fichiers php?
pfrize a écrit:
Pour moi, PWG est un outil de gestion de contenu orienté photo. Je ne vois vraiment bien peu de différences de fond entre Wordpress et PWG: même langage, même SGBD, même couple fondamental d'affichage résumé/développé (dans WP : excerpt/post - dans PWG : vignette/photo), même fonctionnalité de "templating" (avec des solutions techniques différentes il est vrai), même système de catégories, de calendrier, de commentaires, etc. etc. Je dis cela dans un sens positif : PWG est un outil évolué, et pourrait par exemple facilement se présenter (aussi) comme un outil de "photoblogging" tout-à-fait complet (suffirait d'afficher les photos récentes avec un format "blog", et qq autres aménagements).
Je suis assez d'accord avec toi, c'est ce vers quoi on s'oriente de plus en plus.
C'était surtout pour faire un clin d'oeil à z0rglub.
Ça pose quand même 2 questions :
1) ce n'était pas le positionnement initial de PWG, attention à ne pas perdre trop de monde en route,
2) je ne suis pas certain que l'équipe soit suffisamment nombreuse pour se lancer à fond dans cette voie.
<:o)
VDigital a écrit:
pfrize a écrit:
[...] l'équipe de projet ne doit plus perdre de temps à répondre à des questions de cet ordre.
Philippe, c'est vite dit quand même, non? C'est un peu mon rôle d' assister les débutants. Tu n'as jamais sans doute appris à marcher, tu savais déjà avant même de le faire. Personne ne t'a jamais "coaché".
Tu as raison, bien sûr - mais je vois tout de même beaucoup de réponses à des questions de base qui disent : "lis la doc d'abord, puis repose ta question si tu n'as pas trouvé la réponse". Donc on peut penser que plus la doc est complète et claire, moins il y a de questions de base !
chrisaga a écrit:
Pour ce qui est des comparaisons avec Wordpress, ou équivalent : S'il te plait z0rglub, viens nous rappeler encore une fois que PWG n'est qu'une galerie de photo et non un nouvel outil de gestion de contenu.
Pour moi, PWG est un outil de gestion de contenu orienté photo. Je ne vois vraiment bien peu de différences de fond entre Wordpress et PWG: même langage, même SGBD, même couple fondamental d'affichage résumé/développé (dans WP : excerpt/post - dans PWG : vignette/photo), même fonctionnalité de "templating" (avec des solutions techniques différentes il est vrai), même système de catégories, de calendrier, de commentaires, etc. etc. Je dis cela dans un sens positif : PWG est un outil évolué, et pourrait par exemple facilement se présenter (aussi) comme un outil de "photoblogging" tout-à-fait complet (suffirait d'afficher les photos récentes avec un format "blog", et qq autres aménagements).
Philippe
Pour ce qui est des comparaisons avec Wordpress, ou équivalent.
S'il te plait z0rglub, viens nous rappeler encore une fois que PWG n'est qu'une galerie de photo et non un nouvel outil de gestion de contenu.
<:o)
Bon un début de réponse pour que, sans brider les innovations, on évite de réinventer la roue.
rub a écrit:
En fait, je me demande si ca ne serait pas plus simple de faire un nouveau template simplement en modifiant les css et sans touché aux tpl. Du moins faire quelque chose, qui permettent de gérer les 90% des nouveaux templates.
Excellent ! ce que tu décrit, c'est toute la notion de thème qui a été séparée du reste du template dans la version 1.6 justement pour ça.
Un thème, ce n'est pas que des couleurs (Cf. hk-3 pour yoga)
rub a écrit:
Pourquoi, ne pas séparer complementement les fichiers tpl et les fichiers css!
En fait, ça ne simplifie rien.
Les css qui sont laissée dans le template servent à deux choses :
- structurer les éléments de base (formulaires, inputs, icones en toolbar, ...)
- donner une structure de base au template.
Ces règles peuvent être surchargées par le thème si nécessaire. Si on les descend dans les thèmes, ceux-ci vont devenir illisibles et très difficiles à maîtriser pour les non initiés.
On peut en être certains car on revient en fait quasiment à la situation précédente.
Il est intellectuellement moins satisfaisant d'avoir un template constitué de tpl et de css, mais en pratique, ça permet d'isoler dans le thème ce qui à 75% de chances d'être modifié, et ça ne limite pas les possibilités pour les experts qui peuvent toujours surcharger les règles de base.
Nous pouvons encore améliorer tout ça, et surtout, tu as raison prévoir dès le début les id et les classes nécessaires, et éviter de les changer d'une version à l'autre.
pfrize a écrit:
[...] l'équipe de projet ne doit plus perdre de temps à répondre à des questions de cet ordre.
Philippe, c'est vite dit quand même, non? C'est un peu mon rôle d' assister les débutants.
Tu n'as jamais sans doute appris à marcher, tu savais déjà avant même de le faire.
Personne ne t'a jamais "coaché".
Pour moi, les nouveaux utilisateurs apportent des idées différentes des nôtres et nous font progresser tout autant.
A nous de savoir détecter leurs talents (demande à Rub, à rvelices, à nicolas ce qu'ils en pensent).
Personnellement, je sais faire un template différent de A à Z mais quel est l'intérêt?
Le seul intérêt que je vois c'est de faire plus simple et c'est ce qu'à fait z0rglub, il a pris la formule la plus simple.
Faire plus sophistiqué: Oui, mais à titre expérimental parce que, pour adapter les MODs pour des débutants, bonjour !
Prends photon! jillij fait un exellent boulot, et heureusement quand je lui demande, il vient répondre aux questions sur le forum.
De plus, on échappe à toute une série de questions qu'il a en direct sur son forum.
Pour le reste, je suis assez d'accord avec toi.
Une idée aussi à creuser pour toi, que penserais-tu d'avoir au niveau de chaque image la possibilité d'avoir un "class selector"?
Et la même chose au niveau des catégories?
Les templates classiques n'utiliserait pas cette info.
Des TPLs un peu plus boostés y trouveraient des adaptations beaucoup plus spécifiques.
Exemples:
- au niveau des images, des commentaires = display: none;
- au niveau des catégories avoir des :before et :after différents. etc.
8-)
rub a écrit:
Templateurs en herbes et averti comment faites-vous pour faire un nouveau template?
o Vous modifiez les fichiers css?
o Vous modifiez les fichiers tpl? Si oui, c'est surement pour virer des lignes afin de cacher des liens, etc.
Dites-nous ce que vous faites et pourquoi?
Les besoins varient évidemment selon les "templateurs", mais comme qui peut le plus peut le moins... allons-y pour le grand jeu :
Ces besoins relèvent selon moi de 3 catégories, qui correspondent à 3 niveaux d'ambition bien distincts :
1. Le style stricto sensu :
On se borne à modifier polices de caractères, couleurs de texte, de bordures et de fond, aspect des liens (hover...).
Tout cela se traite via les css, et si celles-ci sont correctement documentées (c'est peut-être déjà le cas, je n'en sais rien, je n'ai jamais trop rergardé les css d'origine...), l'équipe de projet ne doit plus perdre de temps à répondre à des questions de cet ordre.
2. La disposition, ou "layout", de la page :
On veut pouvoir choisir les dimensions et l'emplacement des différents éléments qui composent la page, exemples : présence ou absence d'en-tête et de pied-de-page, barre de menu à gauche ou à droite, caractère fixe ou "fluide" (qui s'adapte à la taille du viewport) du cadre principal, présence ou absence de détails d'affichage ("new", nombre de commentaires, etc.).
Tout cela pourrait se traiter théoriquement via les css. Dans la réalité, certains layouts requièrent un remaniement plus ou moins drastique des tpl, pour changer l'ordre des éléments ou encore pour ajouter les balises html nécessaires à un bon fonctionnement "cross-browser' du layout.
3. Les éléments conditionnels ou non-standards de la page :
Il s'agit enfin, à partir de la page standard, d'introduire des éléments supplémentaires, voire sous condition. Quelques exemples pour faire clair :
a) Certaines catégories sont dédiées à des photos "d'art et d'essai" : aucun titre, aucun commentaire, l'image brute ! : j'affiche un groupe de vignettes serrées, sans aucun titre, et les photos pleine page sans commentaires. D'autres catégories sont consacrées à des photos de voyage : là au contraire, j'ai besoin de commenter les images, de raconter le voyage : j'affiche une vignette par ligne avec des explications à droite, et j'affiche chaque photo avec des commentaires ouverts à mes compagnons de voyage.
b) Si page d'accueil, j'affiche un texte de bienvenue - si non, je n'affiche rien.
c) J'ai l'esprit de contradiction, et je souhaite afficher un nuage de catégories et une liste de tags.
d) Je formate les "metada" EXIF OU IPTC de mes photos pour afficher : "photo prise le 29 février 2006 à New York (USA) avec Canon 5d et EF 50mm f/4". Mais pour mon petit musée virtuel, logé dans une autre catégorie, j'utilise un autre format : "peint par Sandro Botticelli en 1483 (National Gallery, London)".
Là, ça se complique : css et tpl ne peuvent suffire, il faut créer ou modifier du code php. Personnellement, ça ne m'ennuie pas, au contraire : j'ai souvent du mal à comprendre un tpl sans analyser le php qui s'y rapporte, donc autant revoir le php directement !
Le choix de certains développeurs d'outils genre Wordpress est de laisser beaucoup de liberté aux utilisateurs imaginatifs, y compris au niveau du code, afin de se consacrer aux choses sérieuses (le "moteur") et de ne pas perdre de temps dans les menus à gauche ou à droite, les titres en bleu ou en rouge, etc. Cela implique de séparer soigneusement le code "sacré" de celui que les utilisateurs peuvent adapter à leurs besoins. Cela facilite aussi la vie des développeurs de plugins, qui peuvent exercer leurs talents sans perturber le coeur du produit (rien de plus exécrable que le système des"mods"). Tout cela favorise le développement d'une communauté d'utilisateurs et l'enrichissement, y compris fonctionnel, du produit de base.
Philippe
Cette semaine, c'est semaine template, on en aura à toutes les sauces.
Comment faire pour simplifier et faciliter la création de nouveaux templates/themes?
C'est une question deja posée plusieurs fois et qui a eu son lot d'évolutions dans la 1.6.0!
Je n'ai jamais fait de nouveau template, mais j'ai simplement modifié le yoga, donc il ne faut pas etre étonné si j'écris n'importe quoi!
Templateurs en herbes et averti comment faites-vous pour faire un nouveau template?
o Vous modifiez les fichiers css?
o Vous modifiez les fichiers tpl? Si oui, c'est surement pour virer des lignes afin de cacher des liens, etc.
Dites-nous ce que vous faites et pourquoi?
En fait, je me demande si ca ne serait pas plus simple de faire un nouveau template simplement en modifiant les css et sans touché aux tpl. Du moins faire quelque chose, qui permettent de gérer les 90% des nouveaux templates.
De plus à chaque nouvelle version, il est nécessaire de remettre les templates/thèmes à jour! Ne pourrait-on pas faire quelque chose, ou il n'y a pas trop de modifs à faire?
Pourquoi, ne pas séparer complementement les fichiers tpl et les fichiers css!
On met les tpl dans un répertoire à eux (à diviser par théme, peut-être), on met les css dans un répertoire à eux par style et par thème.
Ce qui fait:
Maintenant
───template
└───yoga
├───admin
├───icon
│ ├───admin
│ └───mimetypes
└───theme
├───clear
└───dark
└───images
Proposotion
───template
└───structure (toules les fichiers tpl)
├───struct1
├───struct2
└───yoga (style 1)
├───admin
├───icon
│ ├───admin
│ └───mimetypes
└───theme
├───clear
└───dark
└───images
└───style_2
├───admin
├───icon
│ ├───admin
│ └───mimetypes
└───theme
├───clear
└───dark
└───images
C'est dans le style qu'on définira la structure à utiliser (par exemple) ou à l'user ou dans la config.
Et pour ne pas modifier les tpl, il faudrait ajouter des options par thémes (à mettre dans themeconf.inc.php) ou par style (nouveau fichier styleconf.inc.php) ou pourquoi par le biais de css (mais comment? pas info dans les class? c'est obscure).
A la fin, à chaque nouvelle version de PWG, il sera peut-être pas ou peu nécessaire de modifier les styles proposés.
Et on aurait 3 notions:
o template/structure (les fichier tpl)
o style(ancienne notion = template)
o théme
Et pour finir, il faudrait définir, quelque soit le style, et par défaut les classes, pour éviter de devoir modifier un style entre 2 versions!
Lé débat est lancé!