Annonce

Écrire une réponse

Veuillez écrire votre message et l'envoyer

Cliquez dans la zone sombre de l'image pour envoyer votre message.

Retour

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?






http://www.afm-telethon.fr/img/common/logo/AFM-telethon.png

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).

Pied de page des forums

Propulsé par FluxBB

github twitter newsletter Faire un don Piwigo.org © 2002-2024 · Contact