GALERIE PHOTO DYNAMIQUE GÉRÉE PAR MOTEUR TEMPLATE

Commentaire de malalam le 08/09/2007 10:24:55 administrateur CS

Hello,

je vais être un peu dur...
il y a pas mal de choses à dire : déjà des galeries sur phpcs, il y en a des tonnes. Et la tienne n'ajoute absolument rien à celles existantes, que ce soit en termes de fonctionnalités, ou de code.
Parlons du code: il n'apporte rien pédagogiquement parlant (j'aurais accepté un source déjà existant en de multiples exemplaires sur phpcs, mais possèdant un code intéressant, qui peut apprendre des choses aux débutants). C'est du code de débutant.
Ca manque de fonctionnalités, donc, je l'ai dit.
Tu utilises un moteur de template (outre le fait que je ne suis pas fan, mais ça, c'est mon avis) qui pèse à lui seul 10 fois plus que tous les fichiers réunis de ta galerie! Franchement, quel intérêt...? Et puis il n'y a qu'à voir tes fichiers modèles pour se convaincre du fait que tinybutstrong ne sert à rien ici.

Juste un coup de pouce, pour t'aider à ajouter au moins une fonctionnalité sympa (ou au moins, virer un problème de ton code) : tu peux, à génération d'une vignette, ajouter la date de création de celle-ci dans son nom. Ainsi, à chaque fois que tu scannes ton répertoire d'images originales pour voir s'il y en a de nouvelles, tu vérifies aussi, pour celles ayant déjà une vignette, leur date de dernière modification (filemtime()) : si cette dernière est postérieure à la date inscrite dans le nom de sa vignette, ben il y a de grandes chance pour que l'image originale ait été modifiée depuis.

Commentaire de malalam le 08/09/2007 12:21:33 administrateur CS

@Codesfalse : Bieeeen! :-) Enfin quelqu'un qui estime que XSL est un moteur de template extraordinaire! Ca me fait plaisir, tien :-)

Commentaire de codefalse le 08/09/2007 16:17:41 administrateur CS

@malalam : En même temps, quand tu regarde les possibilités énormes que tu a avec, ya rien à dire ! :) c'est juste chiant au début à comprendre la syntaxe, et encore, je trouve que ca rentre encore assez facilement ! :)

@darknessneo
Oui je sais que c'est pas très agréable d'entendre dire qu'il vaut mieux utiliser un moteur de template (type tbs) et qu'ensuite on te dit que finalement non. Mais mon avis sur la chose à aussi tres fortement évolué. Je vais t'en faire part.
En fait, tout d'abord, grace à tbs, je pense que t'a déjà pas mal appris sur comment découper ton travail pour le traitement et l'affichage (et le stockage des données, MVC : Modèle, Vue, Controleur).
C'est déjà une grande étape, ce qui n'est pas négligeable.
Maintenant, utilser un moteur xsl, c'est l'étape suivante, encore plus performante.
Je m'explique : Tu crée un fichier xml, genre :
<page>
  <title>Welcome !</title>
  <menu>
     <item url='index.php'>Accueil</item>
     <item url='images.php'>Mes images !</item>
     ...
  </menu>
  <content><![CDATA[Bienvenue sur mon site cher visiteur blablablablalb]]></content>
</page>

(ca c'est un xml que tu a généré dans ton php)
Tu crée une nouvelle classe Vue (s'il n'en existe pas sur phpcs qui gere le xsl, ca ne saurait tarder :p), et tu importe ton xml, et tu lui dit quelle feuille de style xsl tu lui applique (en général, le nom de la feuille c'est le meme nom que la page en cours, mais avec l'extension xsl), php va effectuer la transformation, et te retourner une page html avec les éléments titre, menu et content remplacés. (Bon, faut apprendre la syntaxe, ca c'est autre chose :))
Jusque là, rien de très différent à ce que tu connais : un code d'origine, un template, une modification.

Mais le gros avantage, c'est que comme à l'origine, tu à un xml, et comme tu le sais tres bien, le xml, ca marche avec tout :p, bah ton xsl, ca peux etre pour un site web, mais aussi pour un téléphone portable en IMode, pour GPS, mais aussi pour une cafetiere (qui gere le navigateur web :p), un frigo, etc ! et Oué, grace au XML/XSL, tu peux afficher ton contenu pour N'IMPORTE quel type d'interpreteur !!!!!!!
(=> je n'ai pas dit de bêtise là-dedans Malalam ? :))

Bon, apres, c'est fortement recommandé d'intégrer dans ton moteur de rendu, une gestion du cache, car la transformation (en php5 c'est mieux supporté) du XML avec XSL, c'est assez lourd parait-il, donc si t'a 500 visiteurs par jours, ton serveur va ptete pas tenir, donc tu met en cache le rendu, et s'il n'y a pas eu de modification, il te retourne le fichier en cache plutot que refaire un rendu !

Euh ... voila ! :)

Commentaire de darknessneo le 09/09/2007 03:25:19

mon site est de type multimedia avec un tres large contenu. Au vus des propos sur ce type de codage, cela est-il vraiment conseillé pour mon site?
Pour le moment mon trafic est relativement faible car mon site vient tout juste de réouvrir ses portes mais qui sait au fil du temps...

Commentaire de malalam le 09/09/2007 09:57:52 administrateur CS

@darknessneo => ce n'est pas incompatible. Déjà, xml et xsl sont des recommendations du w3c aussi. Ensuite, dans xhtml, il y a x pour...xml. Caler un site sur du xhtml, c'est la promesse que des flux xml s'y intègreront très bien.
xsl, via xslt, te permet de transformer un flux xml pour obtenir l'output souhaité : cet output, ce peut être...du html :-) Ou plutôt du xhtml. Ou tout autre output, en fait. le "t" de xslt veut dire transformation.
En fait, xhtml, c'est du xml. Tu peux l'éditer avec le logiciel d'Altova XMLSpy, par exemple, sans soucis. DOMDocument de PHP peut parfaitement parser un flux xhtml (ce qui est très sympa!). xhtml, c'est aussi le standard actuel du web pour une utilisation "normale" (j'entends par là, un ordinateur et un navigateur standards). Ce sera donc ta sortie standard. Maintenant, via xml et xslt, rien ne t'empêche de créer d'autres sorties : ton utilisateur utilise le wap ? Yop, une petite détection, et la sortie devient wap compliant. Tout ce que tu dois faire, c'est créer une feuille xsl pour chaque sortie. Tu veux une sortie pdf ? Sans problème avec xsl-fo.
Mieux encore : tu ne veux que du xhtml, MAIS tu veux pouvoir changer à loisir le format de ton affichage : en colonnes, en lignes, bouger les éléments...encore une fois, xsl-t te permet de le faire à moindre frais. Tu peux même sortir du svg par exemple, pour avoir une sortie entièrement graphique :-) Ou du rtf. Ou le nouveau format de Microsoft, docx. Bref, tout ce qui est créé à partir de balises, en gros.
J'ai écrit il y a quelques temps un petit script qui s'appelle XML MENU, publié ici. Il est petit, pas complet, mais a l'avantage de montrer ces possibilités : tu crées un menu en xml, et il te l'affiche en fonction de différentes feuilles xsl : ici en tableau, là en liste...tu obtiens des affichages très différents, avec pourtant exactement le même flux xml derrière.
Ca va plus loin que les feuilles css parce que tu peux modifier les balises, pas seulement leur appliquer un style de mise en page. Tu peux modifier tout le document, y compris son content-type évidemment.
Et je ne te parle pas de l'encodage :-) C'est difficile à gérer, l'encodage, toujours, mais xml n'est pas un frein, loin de là.

Tu peux même aller plus loin si on reste dans le web : xhtml, c'est du xml. xml accepte tout type de balsies personnelles, si tu crées une dtd ou un schéma. Ben xhtml, c'est pareil...ce qui veut dire que tu peux créé une dtd ou un schéma personel, lier tes documents xhtml avec, et...magie, tes balises et attributs persos s'intègrent parfaitement dans ton xhtml!
Imagine...tu utilises un web service quelconque qui te retourne un flux xml te donnant des indications...je ne sais pas moi, le suivi de colis, par exemple (parce que tu gères une boutique en ligne). Tu peux effectivement utiliser xsl pour modifier ce xml et le transformer via xslt en html, puis l'afficher. Ou tu peux aussi créer un schéma spécialement conçu, qui va indiquer comment le navigateur doit afficher ces nouvelles balises genre <date>18/09/2007</date>. Et avec ta css, en plus, tu leur appliques des styles. Le résultat ? Tu obtiens tout simplement de nouvelles balises xhtml...au même titre que div, span, dd et compagnie.

Il n'y a pas un seul moteur de template php qui offre autant de possibilités et de souplesse.
Et si ton site était encore en html4.0, tu n'aurais pas non plus toutes ces possibilités, d'où l'intérêt de passer au xhtml strict.