Pour la modif de php, nous irons plus loin car nous ne voulons plus de balises HTML dans le php.
a quoi correspond //piwigo/picture.php?/(xx)/category/(x)
Des façons différentes d'atteindre une image, exemples :
L'image 91 : http://fr.piwigo.org/demo/picture.php?/91
L'image 91 visitée via la catégorie 15 : http://fr.piwigo.org/demo/picture.php?/91/category/15
L'image 91 visitée via la catégorie Europe : http://fr.piwigo.org/demo/picture.php?/ … ory/Europe
L'image 91 visitée via le tag 59 (parades) : http://fr.piwigo.org/demo/picture.php?/ … 59-parades
Hors ligne
VDigital a écrit:
Pour la modif de php, nous irons plus loin car nous ne voulons plus de balises HTML dans le php.
excellente nouvelle ! séparer totalement les métiers (SQL, PHP, HTML, CSS ) permet de travailler facilement en équipe
pour le reste je voulais dire que dans picture.php je ne trouve pas la balise img de la grande image
Dernière modification par loick (2009-07-19 14:00:07)
Hors ligne
Forcément car nous utilisons un moteur de template (Smarty)... et que la balise que tu cherches en standard est dans
./template/yoga/picture_content.tpl
Cela permet d'éviter aux gens qui ne connaissent pas php de s'investir outre mesure.
;-)
Hors ligne
loick a écrit:
bon alors j'y vais :-)
et c'est pour cette beta en cours la mise du HTML a part ou pour une version future ?
C'est en cours ;-)
Si tu en trouve n'hésite pas à le signaler dans l'outil bugs and change requests (s'il n'est pas déjà signalé) cela nous permettra d'identifier plus vite ou il en reste et donc de corriger plus vite.
Si tu indiques les modifs à faire cela ira encore plus vite ;-)
Hors ligne
bien sur je peux même le faire et envoyer les fichiers (a contrôler) mais j'ignore si vous avez un genre de convention de nommage pour les class , car si on vire les style faut créer une class
je peux avancer aussi le boulot et vous renommez comme vous voulez
si c'est ok j'envoie ca dans l'outil bugs and change requests en zip ?
Dernière modification par loick (2009-07-19 20:07:57)
Hors ligne
Pour la 2.1, j'ai déjà supprimé quelques focntions de functions_html.inc.php pour les mettre dans les template.
N'hésite pas à récupérer la trunk par svn: http://piwigo.org/svn/trunk/
Par exmple, il me semble que l'icone recent.png a justement changé de place ;-)
Les catégories du menubar et la barre de navigation sont également passées en fichier template.
Pour le reste, je ne me rappelle plus ;-)
Dernière modification par P@t (2009-07-19 20:45:41)
Hors ligne
Je ne trouve pas dans la trunk functions_html.inc.php , j'ai modifiée l'ancien
si ca peut servir (je ne sais pas trop ou le mettre) : functions_html.inc.php + picture_content.tpl (sans styles et avec une class) + new .css (avec les class dedans a sans doute renommer)
http://fs03n2.sendspace.com/dl/ed3ee540 … oStyle.zip
Dernière modification par loick (2009-07-20 06:26:53)
Hors ligne
Si ceci peut t'aider: http://piwigo.org/dev/browser/trunk
Hors ligne
plg a écrit:
Alors déjà, pourquoi on fait du HTML 4 et pas du XHTML ? Remontons ensemble le fil du temps et plaçons nous en 2002. A cette lointaine époque, sortait la version 1.0. Le HTML était du XHTML (peut-être même Strict, il faudrait regarder, là j'ai la flemme). Pourquoi ? parce qu'on disait partout que c'était l'avenir, qu'il ne fallait plus faire du HTML 4. 3 ans plus tard, en 2005, intervient yoDan qui propose une bonne grosse réécriture du HTML (réécriture qui sera intégrée dans Piwigo par chrisaga, d'où le nom du template par défaut : yoga = yo[Dan/chrisa]ga). Et yoDan a dit qu'il préférait utiliser HTML plutôt que XHTML, et les apôtres ont écouté. Moi perso, dans la mesure où yoDan a fait le boulot, qu'il dit HTML c'est mieux que XHTML, je ne me pose pas trop la question : on fait du HTML. Donc depuis la 1.5 et le template yoga, on fait du HTML 4 et pas du XHTML.
Je ne veux pas repolimiquer mais 25 post pour avoir cette réponse, ca ne le fait pas, surtout avec les embrouilles...
loick a écrit:
bon alors j'y vais :-)
,-)
Hors ligne
Je crois que cette polémique html xhtml qui se résume, en caricaturant, a aussi peu que ca : <br> ou <br /> vient de deux mondes du développement : ceux qui utilisent XML/XSLT et donc naturellement verront dans le xhtml du code conforme et des balises repérables du point de vue du xml et de l'autre plutôt les webmaster qui ne veulent pas s'embêter avec ca (bien sur je caricature et je me trompe peut être)
pour l'instant le xml se lit moins vite qu'une base de données (pour de grosses applications) et la transformation xslt est aussi sans doute moins rapide que du php , et le développement en xslt un peu cachet d'aspirine ... mais ca ne sera pas toujours le cas
personnellement j'utilise depuis des années le xml pour faire "tampon" entre les tables MS SQL ou MySQL et les formulaires ou les grilles ainsi par le biais du xml ce sont les tables elles même qui construisent les formulaires
j'utilise aussi le xml pour stocker des galeries d'images a plat pour des petits sites qui bougent peu (et donc sans nécessite de base de données)
un exemple de galerie en xml qui peut se transformer avec xslt (ou n'importe quel langage) en galerie web :
<?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="galerie.xslt"?> <galerie lg="fr"> <infos> <name>blablabla</name> <folder>blablabla</folder> <max>12</max> <titre>blablabla</titre> <title>blablabla</title> <keywords>blablabla</keywords> <description>blablabla</description> </infos> <items> <item id="1"> <photo>blablabla</photo> <alt>blablabla</alt> <title>blablabla</title> <camera>H3D</camera> <lieu>Chamonix</lieu> <date>2007-04-06</date> <raw>7041</raw> </item> <item id="2"> <photo>blablabla</photo> <alt>blablabla</alt> <title>blablabla</title> <camera>H3D</camera> <lieu>Grenoble</lieu> <date>2007-04-12</date> <raw>7642</raw> </item> </items> </galerie>
avec un schema xsd on peut typer les champs
<xsd:element name="photo" type="xsd:string"/>
désolé si c'est un peu hors sujet
Dernière modification par loick (2009-07-20 11:05:57)
Hors ligne
loick a écrit:
j'utilise aussi le xml pour stocker des galeries d'images a plat pour des petits sites qui bougent peu (et donc sans nécessite de base de données)
un exemple de galerie en xml qui peut se transformer avec xslt (ou n'importe quel langage) en galerie web :
Ce n'est pas vraiment hors sujet.
Le xml pour des galeries à plat.
1 - On utilise déjà pour les sites distants et les rapatrier en base de données.
2 - Pour l'usage normal, on ne fige pas des galeries à plat en xml, car nous ne savons pas à l'avance si la galerie et les autorisations d'accès bougent fréquemment sur les galeries de nos utilisateurs ou si elles stables.
3 - De part les notions d'affichage: random, plus vues, ..., par catégories, par tags, etc... avec des images confidentielles (affichable ou pas), avec des autorisations via des catégories, etc...
Face à la quantité de cas différents, la quantité de fichier xml à produire pourrait s'avérer énorme.
Ne perdons pas de vue que nous ne gérons pas des fichiers xml mais des images.
4 - Je connais le principe de fonctionnement des xslt, et j'ai voulu me lancer dans cette voie au début de la mise en place des API Web. Nous n'avions pas dans l'équipe les compétences nécessaire pour aller dans cette direction.
A ce jour, l'usage de galeries à plat stockées sous la forme xml ne me semble pas indispensable surtout quand nous avons des galeries avec des dizaines de milliers de tags et plus de 80 000 photos en ligne.
Cela laisse rêveur c'est un fait mais c'est le cas de notre ami vimages par exemple, et il y en a d'autres.
Hors ligne
VDigital a écrit:
4 - Je connais le principe de fonctionnement des xslt, et j'ai voulu me lancer dans cette voie au début de la mise en place des API Web. Nous n'avions pas dans l'équipe les compétences nécessaire pour aller dans cette direction.
Ah bon ? Vraiment. Sans me vanter je pense que je suis pas loin d'être expert en xslt. En tout cas je suis Monsieur xslt dans ma société! :-)
Hors ligne