Piwigo.org

plg · 2009-01-06 01:04:40

J'aime beaucoup la position de grum sur le sujet. D'ailleurs j'adore le template gally, il est "rafraichissant".

L'avantage avec l'architecture de Piwigo, c'est qu'on peut parfaitement envisager un template "pur HTML/CSS" (ou presque) qui va marcher vraiment partout même sur les interfaces textes, et un template avec des technologies plus actuelles et une utilisation plus intensive de framework Javascript. Comme ça, tout le monde est content (enfin, on s'en approche).

grum · 2009-01-06 07:15:47

z0rglub a écrit:
(...) qui va marcher vraiment partout même sur les interfaces textes (...)

Pour une galerie photo, c'est pas le top quand même ^^;

Dernière modification par grum (2009-01-06 07:15:58)

VDigital · 2009-01-06 09:20:01

grum a écrit:
z0rglub a écrit:
(...) qui va marcher vraiment partout même sur les interfaces textes (...)
Pour une galerie photo, c'est pas le top quand même ^^;

mdr

grum,

Je n'ai pas regardé gally en profondeur pour l'instant.
Dans ton header.tpl tu dois pouvoir coder
{known_script id="jquery" src=$ROOT_URL|@cat:"template-common/lib/jquery.packed.js" }

et introduire les scripts que tu as besoin dans tes tpl.

Ainsi tu as jQuery (en standard dans gally) et tu évites d'éventuel conflits avec les plugins qui tenteraient de doubler la mise.
Mais c'est sans doute ce que tu as déjà fait...

;-)

nicolas · 2009-01-06 10:05:33

L'avantage de jquery (je connais moins les autres) c'est que c'est du javascript non intrusif qui se dégrade proprement si le javascript n'est pas activé.

Je suis en train de faire un plugin de panier utilisateur et je vais utiliser jquery pour ajouter des photos dans le panier. Une première version permettra d'ajouter une image en ajax et une deuxième par glisser/déposer + ajax. Le panier fonctionnera même sans javascript sans ajouter une ligne de code !

rub · 2009-01-06 14:19:35

nicolas a écrit:
Le panier fonctionnera même sans javascript sans ajouter une ligne de code !

Je pense que c'est la méthode que l'on doit garder... plutot qu'un template "pur HTML/CSS"...
Quitte à rajouter une option pour activer la javascript sur la galerie coté publique ou selon le type de brower ou selon détection lecture par pc, téléphone...

VDigital · 2009-01-06 14:45:06

rub a écrit:
Quitte à rajouter une option pour activer la javascript sur la galerie coté publique ou selon le type de brower ou selon détection lecture par pc, téléphone...

(Une option pour activer le Javascript? On saurait faire ça?
Mettre un message recommandant d'activer le Javascript, c'est ce que tu veux dire?)

[rub]Quitte à rajouter une option pour activer l(a)e javascript...[/rub]
Passo dobles (oublions donc) la Java de l'an 9, mais le script pour activer le Javascript, tu repasseras.
Pour la première de l'année, quelle belle perle!
J'hésite à la classer en tant que telle car elle a dépassé ta pensée.
;-)

rub · 2009-01-06 16:54:30

VDigital a écrit:
rub a écrit:
Quitte à rajouter une option pour activer la javascript sur la galerie coté publique ou selon le type de brower ou selon détection lecture par pc, téléphone...
(Une option pour activer le Javascript? On saurait faire ça?
Mettre un message recommandant d'activer le Javascript, c'est ce que tu veux dire?)

Non, non, pas une message bien une option.

Comme gmail par exemple, où tu peux passer en gmail view basic HTML.
Ca, c'est un choix niveau utilisateur.

Mais, il détecte aussi si tu vas sur gmail à partir d'un mobile et te passe en basic HTML par defaut (à qui me semble).

Ensuite une option globale pour l'admin pour déactiver completement le javascript, voir une option au niveau du user.

VDigital · 2009-01-06 17:22:10

Si je désactive le Javascript dans mon naFigateur préFéré, option ou pas ton script ne réactivera jamais le Javascript.
Même gmail ne saura pas activer le Javascript.
Pourtant c'est bien ce que tu avais écrit.

Par contre, par un php, tu peux décider de ne pas inclure les scripts (donc je suis d'accord, que même si le navigateur supporte les scripts, ceux-ci seront en quelque sorte désactivés).

Nez en plus (contraire de néanmoins), je préfère laisser cette gestion au navigateur, nous avons assez de paramètres à gérer, il me semble.

grum · 2009-01-06 20:18:15

VDigital a écrit:
grum a écrit:
z0rglub a écrit:
(...) qui va marcher vraiment partout même sur les interfaces textes (...)
Pour une galerie photo, c'est pas le top quand même ^^;
mdr

grum,

Je n'ai pas regardé gally en profondeur pour l'instant.
Dans ton header.tpl tu dois pouvoir coder
{known_script id="jquery" src=$ROOT_URL|@cat:"template-common/lib/jquery.packed.js" }

et introduire les scripts que tu as besoin dans tes tpl.

Ainsi tu as jQuery (en standard dans gally) et tu évites d'éventuel conflits avec les plugins qui tenteraient de doubler la mise.
Mais c'est sans doute ce que tu as déjà fait...

;-)

Pour l'instant je n'exploite pas jQuery dans Gally, je n'avais pas encore pris le temps de me pencher sur le framework quand j'ai fait le template. Mais cette méthode d'inclusion existant, il n'y a pas de raison que je ne l'exploite pas. Je l'ai utilisée dans Translator pour exploiter le datepicker par exemple.

gbo · 2009-01-06 20:39:50

z0rglub a écrit:
J'aime beaucoup la position de grum sur le sujet. D'ailleurs j'adore le template gally, il est "rafraichissant".

L'avantage avec l'architecture de Piwigo, c'est qu'on peut parfaitement envisager un template "pur HTML/CSS" (ou presque) qui va marcher vraiment partout même sur les interfaces textes, et un template avec des technologies plus actuelles et une utilisation plus intensive de framework Javascript. Comme ça, tout le monde est content (enfin, on s'en approche).

Cela me parait aussi très bien, offrir un maximum de fonctionnalité en laissant l'administrateur définir le mode de fonctionnement de son site.

rub · 2009-01-07 06:56:46

VDigital a écrit:
Si je désactive le Javascript dans mon naFigateur préFéré, option ou pas ton script ne réactivera jamais le Javascript.
Même gmail ne saura pas activer le Javascript.
Pourtant c'est bien ce que tu avais écrit.

Par contre, par un php, tu peux décider de ne pas inclure les scripts (donc je suis d'accord, que même si le navigateur supporte les scripts, ceux-ci seront en quelque sorte désactivés).

Nez en plus (contraire de néanmoins), je préfère laisser cette gestion au navigateur, nous avons assez de paramètres à gérer, il me semble.

Désactiver n'était sans doute pas le bon terme...
Je ne parlais en aucun cas désactiver dans le browser mais bien de ne pas inclure le code....

flop25 · 2009-01-07 16:45:37

grum a écrit:
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.

Bonjour à tous,
j'ai très vite vu le potentiel de Jquery dans les templates en intégrant dans le template FloOs la possibilté de l'utiliser dans les menus premièrement. Seulement le must c'est que j'ai adapté le template pour l'utilisation du Jquery mais ce sont les thèmes qui appellent Jquery via le fichier de config du thème : donc on pourrait aussi modifier un peu yoga pour permettre qq application Jquery appelé par les thèmes donc l'utilisateur peut choisir.

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

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 20:47:56

Et je dis, j'écris: +1 (sinon cela devient à l'usine à gaz).

Piwigo.org

Annonce

#16 2009-01-06 01:04:40

Re: Jquery pour la partie public

#17 2009-01-06 07:15:47

Re: Jquery pour la partie public

z0rglub a écrit:

#18 2009-01-06 09:20:01

Re: Jquery pour la partie public

grum a écrit:

z0rglub a écrit:

#19 2009-01-06 10:05:33

Re: Jquery pour la partie public

#20 2009-01-06 14:19:35

Re: Jquery pour la partie public

nicolas a écrit:

#21 2009-01-06 14:45:06

Re: Jquery pour la partie public

rub a écrit:

#22 2009-01-06 16:54:30

Re: Jquery pour la partie public

VDigital a écrit:

rub a écrit:

#23 2009-01-06 17:22:10

Re: Jquery pour la partie public

#24 2009-01-06 20:18:15

Re: Jquery pour la partie public

VDigital a écrit:

grum a écrit:

z0rglub a écrit:

#25 2009-01-06 20:39:50

Re: Jquery pour la partie public

z0rglub a écrit:

#26 2009-01-07 06:56:46

Re: Jquery pour la partie public

VDigital a écrit:

#27 2009-01-07 16:45:37

Re: Jquery pour la partie public

grum a écrit:

#28 2009-01-07 18:00:28

Re: Jquery pour la partie public

#29 2009-01-07 20:37:26

Re: Jquery pour la partie public

#30 2009-01-07 20:47:56

Re: Jquery pour la partie public

Pied de page des forums