🌍
Français
Piwigo.org
Annonce
- [2024-11-11] Piwigo 15.1.0 : petites correction et infos sur les nouveautés
- [2024-10-22] Piwigo 15
- [2024-09-25] Piwigo 15.0.0RC1, on est proche du but
- [2024-09-11] Piwigo 15.0.0beta3
- [2024-08-01] Piwigo 15.0.0beta2
- Accueil forums
- » Demandes de fonctionnalité
- » Jquery pour la partie public
Écrire une réponse
Résumé de la discussion (messages les plus récents en premier)
- grum
- 2009-12-05 10:30:07
VDigital a écrit:
Un et un seul plugin pourrait permettre de Switcher la version de jQuery utilisée, passer en 1.3.2, revenir en 1.2.6.
Ceci afin de tester une nouvelle version. Cela permettrait de lever cette contrainte.
çà, çà semble être c'est une bonne idée, un plugin pouvant être mis à jour plus facilement que Piwigo.
- VDigital
- 2009-12-05 08:30:22
grum a écrit:
je ne suis pas convaincu à l'idée d'avoir sur une galerie plusieurs frameworks différents.
+1 (exemple: post124484)
grum a écrit:
Par contre, il faudrait que Piwigo suive plus régulièrement l'évolution de jQuery.
+1
Un et un seul plugin pourrait permettre de Switcher la version de jQuery utilisée, passer en 1.3.2, revenir en 1.2.6.
Ceci afin de tester une nouvelle version. Cela permettrait de lever cette contrainte.
rvelices, peut-être, ton avis?
- grum
- 2009-12-05 03:33:37
Je rejoins Vincent sur le sujet : au niveau plugins&templates, s'il y usage de jQuery il m'est avis qu'il est préférable de n'utiliser que la version de jQuery livrée avec Piwigo : çà évite entre autres les conflits.
Concernant l'usage de jQuery.noconflict, je ne suis pas convaincu à l'idée d'avoir sur une galerie plusieurs frameworks différents.
Par contre, il faudrait que Piwigo suive plus régulièrement l'évolution de jQuery.
Piwigo en est à la 1.2.6 alors que jQuery en est à la 1.3.2
Je revois actuellement mes templates et je pousse un plus dans l'usage de jQuery => grosse(s) frustration(s) car les démos sur le site de jQuery sont en 1.3.2, et forcément certaines options avec la 1.2.6 ne fonctionnent pas. Obligé donc de devoir recoder à la mano des fonctions présentes dans la 1.3.2 (perte de temps + intégration pas aussi bien que si c'était natif...)
- VDigital
- 2009-12-04 07:28:15
Bien joué, Pierre.
C'est évident, mais ce n'est ni aux thèmes ni aux plugins de mettre à dispo jQuery en partie publique ou alors il doivent le faire comme prévu dans les règles de l'art (definie avec rvelices, lors de la mise en place):
{known_script id="jquery" src=$ROOT_URL|@cat:"template-common/lib/jquery.packed.js"}
Et bien entendu, on ne doit pas livrer une autre version du core afin d'éviter tout conflit.
La syntaxe du id est très importante.
d'autres exemples:
{known_script id="jquery.ui" src=$ROOT_URL|@cat:"template-common/lib/ui/ui.core.packed.js"}
{known_script id="jquery.ui.tabs" src=$ROOT_URL|@cat:"template-common/lib/ui/ui.tabs.packed.js"}
Mais jQuery.noConflict() est un plus. Cela veut dire qu'on va abandonner en standard l'usage du $("xxxxx") en partie publique à priori.
- repie38
- 2009-12-04 01:51:44
VDigital a écrit:
Je n'ai pas encore regardé mais j'imagine déjà une solution pour que les thèmes puissent également ajouter des scripts jQuery sans créer de conflit pour autant.
topic:16565
je viens de resoudre une incompatibilité entre pamooramics et simple/grey ainsi que gally (qui integrent deja du jquery en partie publique).
jQuery ne devrait pas etre utilisé en partie publique sans l'emploi de la methode jQuery.noConflict()
c'est la seule librairie a ma connaissance ayant une telle fonctionnalité, et donc a elle de se rendre compatible ...
- rub
- 2009-01-19 07:50:31
P@t a écrit:
Il faut bien tout vérifier avec plusieus navigateurs... Drag and drop, text resize, etc...
C'est pour ca que je l'ai fait en trunk et uniquement en trunk...
D'ailleurs en parlant de navigateur: topic:14695
- P@t
- 2009-01-19 00:46:03
Il faut bien tout vérifier avec plusieus navigateurs... Drag and drop, text resize, etc...
Je me demande si j'avais pas eu un soucis avec une version de jquery et le drag and drop.
Et je ne peux pas vérifier maintetant :-(
- rub
- 2009-01-19 00:29:05
[Subversion] r3102 & [Subversion] r3103
Uniquement pour la trunk, j'ai mis à jour avec la dernière version stable de jQuery UI (jquery.ui-1.5.3.zip).
J'ai changé l'arborescence pour coller à celle de UI.
J'ai aussi ajouter de les js pour les effets...
Pas de soucis?
- flop25
- 2009-01-10 16:01:35
VDigital a écrit:
J'ai dans l'idée que ce n'est pas themeconf.inc.php qui peut incorporer les scripts.
Par contre, themeconf peut sans doute forcer l'usage d'un template-extension lequel activera ultérieurement les scripts jQuery.
jusque-là j'utilise themeconf , mais l'idée de la complémentarité possible avec des extension me parait plaisant aussi
Sinon :
grum a écrit:
D'un point de vue perso, le thème doit rester essentiellement voir exclusivement du CSS.
C'est le template qui a vocation à piloter les modifications de l'interface que le CSS ne permet pas.
Si on commence via les thèmes à faire des interventions normallement réservées aux templates, autant se séparer du système template/thème pour n'avoir qu'un seul système qui fait les deux (mais perso je suis pas trop pour).
Le template fait dans la structure mais les js peuvent être activé via les thèmes Pourquoi c'est très utile ? Car tu poux faire des thèmes avec OU sans js à partir du même graphisme css. Dès lors tu peux proposer pour ceux qui n'aime pas le js des versions sans, et pour ceux qui n'ont pas peur d'alourdir les pages des versions avec et dès lors améliorer le css pour l'utilisation du js. Tout cela à partir du même template !
grum a écrit:
Et toujours d'un point de vue perso, le template yoga doit rester un template simple (du html, un peu de js dans quelques cas particuliers, et du css).
Si l'on souhaite ajouter au paquet de base de Piwigo une interface avec du js, c'est un second template qu'il faut mettre en place.
Je ne parlais pas de rajouter du js sur le template mais via certains thèmes. Ce serait des modif du type html uniquement à faire sur le template pour permettre certains trucs dépliables etc Mais il faut y réfléchir avant pour penser qui modifier. Mais de toute façon il un peu trop tard pour que la team y réfléchisse
- rub
- 2009-01-09 13:24:46
Je suis pas vraiment d'accord...
Ok à 100% sur les définitions des thèmes et des templates mais actuellement, il me semble pénible de maintenir 2 templates (bravo à flop25)...
2 templates ok mais il faut progresser sur les templates (comme on l'a fait dans 2.0) avec les substitions...
Il manque simplement qu'un template X hérité du template Y... Le plus simple, c'est si une page toto.tpl n'existe pas en template X, il prend celle du template Y...
Ensuite pour ajouter du JS dans les pages, je pense que les plugins sont aussi un très bon moyen... Prenons l'exemple de ce qui a été pour l'admin en 2.0, une fois que les sélecteurs sont bien positionnés (et encore), tout aurait pu être mis dans un plugin...
- grum
- 2009-01-07 23:40:41
z0rglub a écrit:
Quelle sagesse dans ses écrits.
^^;
çà vient avec l'âge....
:o)
- plg
- 2009-01-07 22:20:22
grum a écrit:
Et toujours d'un point de vue perso, le template yoga doit rester un template simple (du html, un peu de js dans quelques cas particuliers, et du css).
Si l'on souhaite ajouter au paquet de base de Piwigo une interface avec du js, c'est un second template qu'il faut mettre en place.
+1
Quelle sagesse dans ses écrits.
- VDigital
- 2009-01-07 20:47:56
Et je dis, j'écris: +1 (sinon cela devient à l'usine à gaz).
- grum
- 2009-01-07 20:37:26
D'un point de vue perso, le thème doit rester essentiellement voir exclusivement du CSS.
C'est le template qui a vocation à piloter les modifications de l'interface que le CSS ne permet pas.
Si on commence via les thèmes à faire des interventions normallement réservées aux templates, autant se séparer du système template/thème pour n'avoir qu'un seul système qui fait les deux (mais perso je suis pas trop pour).
Et toujours d'un point de vue perso, le template yoga doit rester un template simple (du html, un peu de js dans quelques cas particuliers, et du css).
Si l'on souhaite ajouter au paquet de base de Piwigo une interface avec du js, c'est un second template qu'il faut mettre en place.
- VDigital
- 2009-01-07 18:00:28
Je n'ai pas encore regardé mais j'imagine déjà une solution pour que les thèmes puissent également ajouter des scripts jQuery sans créer de conflit pour autant.
C'est à étudier à moins que rvelices aie pris encore un peu d'avance sur ce point.
J'ai dans l'idée que ce n'est pas themeconf.inc.php qui peut incorporer les scripts.
Par contre, themeconf peut sans doute forcer l'usage d'un template-extension lequel activera ultérieurement les scripts jQuery.
Je suis certain de parler chinois pour la grande majorité.
Mais quand Flop25, ou un autre concrétisera cette logique par un exemple cela deviendra accessible à un plus grand nombre (bien que cela relève des fonctions les plus avancées de Piwigo).