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.
Hors ligne
z0rglub a écrit:
Quelle sagesse dans ses écrits.
^^;
çà vient avec l'âge....
:o)
Hors ligne
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...
Hors ligne
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
Hors ligne
[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?
Dernière modification par rub (2009-01-19 00:32:36)
Hors ligne
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 :-(
Hors ligne
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: [Forum, topic 14695] [2.0.0.RC4svn] Piwigo, jQuery et Chrome
Hors ligne
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.
[Forum, topic 16565] paMOOramics ne marche pas style simple/grey
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 ...
Hors ligne
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.
Hors ligne
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...)
Hors ligne
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?
Hors ligne
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.
Hors ligne