🌍
Français
Je ne suis pas non plus incompétent en la matière, mais franchement l'implémentation de l'API web (autrement appelé un peu abusivement "webservices") est très bien, voire trop complète, j'aurais uniquement fait du JSON en sortie. Je suis hors sujet désolé.
nicolas a écrit:
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é! :-)
C'est très bien, maintenant on est parti dans une autre direction mais si l'occasion de mettre en œuvre se présente, je t'appelle.
Il faudrait qu'on propose au moins un schema avec une application exemple.
Les seules expériences du xlst que j'ai ne sont pas très probantes...
1/ des documents MS Office qui font des presques des mégaoctets pour stocker "Bonjour" en police Arial taille 12
2/ des flux de données où comme 98% de la taille du flux est liée aux balises, on est obligé de réduire le nombre de données pour arriver à des temps de traitements acceptables
Donc même si dans la théorie j'adhère, dans la pratique rien ne vaut une bonne copy COBOL..... ;o)
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é! :-)
bien sur et aussi multiplier les langages n'est peut être pas le mieux
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.
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
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 :-)
,-)
merci
Si ceci peut t'aider: http://piwigo.org/dev/browser/trunk
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
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 ;-)
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 ?
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 ;-)
bon alors j'y vais :-)
et c'est pour cette beta en cours la mise du HTML a part ou pour une version future ?