Project

General

Profile

Anomalie #4736

nouveau date picker et la modalbox ou les crayons dans le public

Added by tofulm - 28 days ago. Updated 26 days ago.

Status:
Fermé
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
04/16/2021
Due date:
% Done:

0%

Resolution:
wontfix
Navigateur:

Description

Merci pour le nouveau datepicker.

Pour faire fonctionner le datepicker dans le public, j'ai ajouté l'inclure dans inclure/head.html pour l'avoir sur toutes les pages :

[(#INCLURE{fond=formulaires/dateur/inc-dateur})]

Seulement, le datepicker s'initialise seulement si dans la page, il y a un input.date ou .heure
https://git.spip.net/spip/spip/src/commit/21097aece89c1bcb9fed25a3ce0a1effdc792c49/prive/formulaires/dateur/inc-dateur.html#L105

Si sur une page il ne contient pas un input.date et que l'on appelle un modalbox ou un crayon avec un input.date, la datepicker n'est pas activé.

Pour palier provisoirement, j'ai forcé l'initialisation du datepicker à la suite de l'INCLURE dans inclure/head.html

Y aurait il une solution plus propre

History

#1 Updated by cedric - 28 days ago

  • Status changed from Nouveau to Fermé
  • Resolution set to wontfix

Alors, comment dire...

1/ Le core fournit un date-picker à usage interne pour l'espace privé, et une méthode de chargement associée
2/ il n'a jamais été supporté que ce date picker ait vocation à être utilisé dans le site public
3/ en conséquence, aucune méthode de chargement pour l'espace public n'a jamais été proposée ni garantie
4/ en pratique inclure le inc-dateur dans un formulaire marche également dans le site public, que le formulaire soit chargé dans la page principale ou dans un formulaire chargé dans une brique ajax, et cet usage s'est répandu, notamment via saisies et formidable
5/ c'est la seule et unique méthode officielle supportée, toute autre relève du hack

Alors insérer le inc-dateur dans le <head> ça me parait totalement une mauvaise idée, mais chacun fait bien ce qu'il veut du moment qu'il demande pas ensuite à la team core de gérer les bugs qui vont avec...

(et il n'y a amha aucune bonne raison de faire ça : personne ne veut charger un script js "sur toutes les pages au cas où")

#2 Updated by nicod _ 28 days ago

Avec saisies ça juste marche, en cochant éventuellement "Charger le javascript et les CSS sur toutes les pages" dans la config pour les popins et autres modales.

#3 Updated by b b 28 days ago

nicod _ a écrit :

Avec saisies ça juste marche, en cochant éventuellement "Charger le javascript et les CSS sur toutes les pages" dans la config pour les popins et autres modales.

Ça ne fonctionnait justement pas de manière automatisée, j'ai souvent fourbé de manière honteusement sale pour ça cf https://github.com/brunob/octopouce/commit/99cb1151359950554d0d0c16ec1fa458ab5ed0fb ; et si ça ne fonctionnait bien qu'en cochant une case de config pour charger js et css dans le public, je pense qu'on peut palier ça dans le core avec une bonne doc, car on ne souhaite surtout pas ajouter de clicodrome dans le core :)

#4 Updated by tofulm - 28 days ago

(et il n'y a amha aucune bonne raison de faire ça : personne ne veut charger un script js "sur toutes les pages au cas où")

Si tu utilises spip pour faire un outils métier, et non pas un site vitrine, alors, oui tu peux charger un js sur toutes les pages. C'est bien dommage qu'il y est justement ce cloisonnement privé / public, mais là n'est pas la question.

#5 Updated by RastaPopoulos ♥ 27 days ago

Je suis d'accord pour dire qu'il faut le moins de hack etc ok.

Pour autant je ne suis pas d'accord effectivement avec l'argumentation "ça a été fait que pour l'admin de SPIP".

De mon point de vue, à peu près tout ce qui est fonctionnel ne fait pas du tout partie de "l'admin de SPIP". D'ailleurs un jour (quand on redécoupera pour Composer par ex) il faudrait déplacer ces éléments dans un autre dossier afin de mieux comprendre (et ça nous forcera à bien faire attention à ce que ces éléments marchent ailleurs)

D'un côté le core fournit des briques fonctionnelles (API, formulaires insérables partout, etc), et de l'autre on a une interface d'admin par défaut, qui est une manière (couvrant 95% des besoins) de présenter l'administration du site. Mais toutes les briques fonctionnelles doivent être utilisables ailleurs que dans l'admin. Notamment tous les formulaires CVT sont insérables ailleurs et doivent fonctionner. Et donc si un form d'un objet à un champ pour choisir une date, que ce soit de la dist ou editer_evenement d'Agenda ou autre, ça doit marcher qu'on soit dans l'admin ou qu'on l'utilise ailleurs.

Que quelques rares fonctionnalités ne soient prévues que pour l'admin ok, par ex les forms de SVP, la gestion des plugins, c'est logique. Mais "avoir un champ date" c'est tellement courant, que ça ne devrait pas être cloisonné à l'admin.

#6 Updated by b b 26 days ago

Et donc si un form d'un objet à un champ pour choisir une date, que ce soit de la dist ou editer_evenement d'Agenda ou autre, ça doit marcher qu'on soit dans l'admin ou qu'on l'utilise ailleurs.

Je ne voudrais pas parler à la place de Cedric, mais si je ne me trompe pas, c'est exactement ce qu'il décrit par :

4/ en pratique inclure le inc-dateur dans un formulaire marche également dans le site public, que le formulaire soit chargé dans la page principale ou dans un formulaire chargé dans une brique ajax, et cet usage s'est répandu, notamment via saisies et formidable
5/ c'est la seule et unique méthode officielle supportée, toute autre relève du hack

Le dateur fonctionne si le formulaire qui l'utilise fait l'inclure qui va bien, ici tofulm tente d'inclure ce js dans le head de toutes les pages de son site, ce qui me semble un tout autre usage.

Also available in: Atom PDF