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

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.

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

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?

J'essaye d'adresser cette question dans le topic 7722