Pour l'instant nous avons choisi de ne pas l'intégrer.
Cependant les auteurs de plugins doivent coder dans leur .tpl:

{known_script id="jquery" src=$ROOT_URL|@cat:"template-common/lib/jquery.packed.js" }

Pour les autres scripts déjà dispos, ils trouveront l'id correspondant dans les différents templates de l'admin.
Merci de ne pas dupliquer un script déjà présent dans la release 2.0.0

EX-FTB a écrit:

je ne suis pas favorable à l'intégration d'office  sur la partie public de tout élément alourdissant le premier affichage de la galerie.

Il faut que l'utilisateur final (ou le gestionnaire du site)  puisse choisir en comparant  les avantages de l'ajout  de fonctionnalité
par rapport  à la dégradation du temps de réponse.

100% d;accord avec toi pour le moment - probablement d'ici 2-3 ans a revoir la position par rapport au sujet ...

Il ne faut pas exagérer. La librairie jquery le fait qu'un peu plus de 20Ko et elle n'est téléchargée que sur la première page. Après elle est en cache. En revanche il faut bien garder le numéro de version et ajouter les entêtes de cache correcte pour que le fichier soit gardé longtemps dans le cache du navigateur;

Après pour le problème des scripts codés avec les pieds, on ne peut pas faire grand chose. Le problème reste toujours l'interface entre la chaise et le clavier.

z0rglub a écrit:

VDigital a écrit:

Nous avons essayé de nous contenter de jQuery en Admin et déjà nous avons été confrontés à un grand nombre de conflits entre les scripts.

Quels conflits entre quels scripts ? (je ne le sais pas, c'est une question naïve)

A titre personnel, j'aimerais intégrer plus de dynamisme côté navigateur sur la partie navigation (pouvoir passer d'une photo à une autre sans recharger toute la page par exemple). Mais ça pourrait être dans une template extension alternative, pas forcément un point de passage obligé.

Conflits? Rub et Pat, de mémoire c'est vous qui avez dû revoir vos premières versions, non?

A titre personnel, et au titre de l'équipe, tu peux le dire... Dès que vous avez vu Accordion dans la partie Admin, cela vous a donné des idées et rvelices nous a déjà fait le rating et les commentaires sans rechargement de la page picture.
Mais je ne voudrais pas comme rvelices que les scripts faussent le jugement des propriétaires de galeries quand aux capacités et aux performances générales de Piwigo. (Séparons les problèmes).

P@t a écrit:

VDigital a écrit:

Conflits? Rub et Pat, de mémoire c'est vous qui avez dû revoir vos premières versions, non?

On a eu un petit soucis avec le premier plugin utilisé pour la taille automatique des textarea...
Perso, j'ai eu aussi un ptit soucis avec une version de jQuery et le drag&drop.
Donc d'accord avec vincent, il faut bien tout vérifier avant de proposer du jQuery coté publique... pas de précipitation!

Et ce n'était pas un plugin de jQuery... simplement un plugin utilisant jQuery...
Mais, c'est normal d'avoir ce genre de soucis lorsqu'on développe...

Imagine que tu aies besoin du framework "plume" (par exemple).

Tu officialises sur le forum que "plume" se déclare ainsi:
{known_script id="plume" src=$ROOT_URL|@cat:".../lib/.....js" }

flipflip a écrit:

Maintenant pour l'intégration ou non côté public je vous laisse voir, mais vous avez ouvert une porte et vue la mode des sites "top fashon moumout en poil de Choyui"... Vous n'y échapperé pas :(

Les sites "top fashon moumout en poil de Choyui" c'est bien aussi.
Perso, même çà à le mérite d'être fonctionnel -et c'est l'essentiel- je trouve que l'IHM publique de Piwigo est un peu trop austère en terme d'intéractivité.


Jusqu'à présent, je n'étais pas trop pour l'usage intensif du js :
- les normes du W3C ne sont respectées par tous les navigateurs
- quand les normes sont implémentées, les réactions des navigateurs ne sont pas toujours les mêmes
- quand c'est mal codé (et avec le js on code facilement très mal) çà peut être la cause de ralentissements
- une perte de temps énorme à corriger des fonctions qui fonctionnent très bien sur un navigateur mais pas sur un autre

Maintenant, trois choses me laisse penser que l'on peut franchir le pas :
- les frameworks, qui permettent de s'affranchir d'une grande partie des problèmes de compatibilité entre les navigateurs
- les navigateurs, qui évoluent : les pires (IE5, IE6 pour ne pas les citer) seront d'ici quelques temps abandonnés au profit d'autres navigateurs déjà plus ouvert au web "2.0" (IE7 pas glop mais c'est déjà mieux qu'IE6, et IE8 devrait normallement respecter les normes... çà reste à voir ^^;)
- j'ai vu bon nombre de sites sur lesquels disposer d'une interface interactive est une chose vraiment agréable

La première évolution peut se faire au niveau des plugins et des templates sans pour autant toucher au coeur de Piwigo. Des évolutions de ce type laissent le choix à tous de faire usage ou non de ce qui est proposé.
Pour ma part j'ai commencé un peu avec Gally, mais je n'ai pas encore eu le temps de mettre en place tout ce qui fourmille dans ma tête ; la prochaine version du template exploitera probablement jQuery de façon intensive.