Advanced search

On other websites (4011)

• Evolution #4641 (Fermé): Des rechargements Ajax avec des transitions personnalisables

  19 February 2021, by cedric -

  Il y a 1 seule règle css en dur, c’est le opacity, pour palier aux cas des gens qui n’ont pas de css pour gérer le loading des bloc ajax.
  Mais il y a sinon déjà une class loading qui est mise en début de chargement.

  Pour le reste, on peut sans doute améliorer le code, mais je rappelle qu’il est déjà totalement possible d’ajouter des callbacks pour gérer le chargement de bloc ajax : https://git.spip.net/spip/spip/src/branch/master/prive/javascript/ajaxCallback.js#L486
  en gros il suffit que tu ajoute un data-loaded-callback sur un bloc ajax pour prendre la main et traiter à ta façon l’affichage du contenu ajax, donc avec toutes les transitions qui te feront plaisir :)

  Autrement dit, jusqu’à preuve du contraire, il y a tout ce qu’il faut pour traiter ce sujet en plugin, et on pourra toujours discuter de ce qui doit intégrer le core à ce moment là. Du coup je ferme ici

• Evolution #4641 (Nouveau): Des rechargements Ajax avec des transitions personnalisables

  27 January 2021

  En me penchant sur les librairies JS de transitions entre pages telles que https://barba.js.org ou https://swup.js.org, je me faisais la réflexion qu’on a déjà quasiment tout ce qu’il faut dans Spip pour avoir l’équivalent avec les rechargements de blocs Ajax.

  Il ne s’agirait pas d’ajouter une ces libs hein, mais juste d’étendre le mécanisme actuel dans ajaxCallback.js, ce qui devrait permettre de reproduire la chose à peu de frais (pour les blocs ajax, pas des pages entières donc).
  Je n’ai pas encore regardé en détail, mais il semblerait qu’il ne manque pas grand chose.

  Pour rappel, ces libs reposent entièrement sur des animations CSS pour les transitions, animations personnalisables au cas par cas : c’est souple et facile à personnaliser.
  Des classes sont ajoutées au conteneur pour indiquer chaque étape (couplé à des events JS) : quand l’ancien contenu part, quand le nouveau arrive, etc.
  Exemple pour Swup : https://swup.js.org/getting-started/how-it-works.
  Exemple pour Barba : https://barba.js.org/docs/getstarted/lifecycle/

  Pour nos rechargements ajax c’est déjà un peu pareil, il y a plusieurs étapes (début du chargement, fin du chargement), sauf que les styles CSS sont mis en dur : .css('opacity', 0.5)

  Donc ce que j’imagine, c’est ça :

  • Ne plus mettre des styles en dur, mais des classes CSS. Par défaut il s’agirait par exemple de .ajax-transition-defaut.
  • Découper le chargement en autant d’étapes que nécessaires, chaque étape appliquant une classe au bloc, par exemple : .ajax-loading-beforeleaving, .ajax-loading-isleaving, .ajax-loading-afterleaving, etc.
  • Chaque étape ne doit appeler la suivante qu’une fois l’animation (optionnelle) de l’étape précédente terminée. C’est une chose possible en JS (attendre la fin de l’anim du bloc ciblé). Par exemple si un⋅e intégrateur⋅ice décide que son animation de départ et d’arrivée prend 10s, ça la regarde, on n’impose rien.
  • Enfin, permettre de choisir l’animation désirée pour chaque bloc, au cas par cas. Il pourrait s’agir par exemple d’un paramètre réservé en complément de `ajax` :

  Le but c’est que ça reste facilement prenable en main par les intégrateurs et intégratrices.

  Exemple concret.

  Mettons que je veuille une animation personnalisée pour un bloc, je lui donne un identifiant :

  <span class="CodeRay"><span class="tag">span><span class="error">{</span><span class="attribute-name">fond</span>=<span class="attribute-value">truc</span><span class="error">,</span> <span class="attribute-name">ajax</span>=<span class="attribute-value">machin</span><span class="error">,</span> <span class="attribute-name">ajax_transition</span>=<span class="attribute-value">mojito</span><span class="error">}</span><span class="tag">></span>
  
  </span></span>

  La transition personnalisée est ajoutée comme classe au bloc ajax, ainsi que l’étape actuelle mise à jour au fil du chargement :

  <span class="CodeRay"><span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">ajaxbloc ajax-id-machin ajax-transition-mojito ajax-loading-[etape_du_chargement]</span><span class="delimiter">"</span></span> <span class="attribute-name">data-ajax-env</span>=<span class="string"><span class="delimiter">"</span><span class="content">…</span><span class="delimiter">"</span></span><span class="tag">></span>
  
  </span></span>

  Il reste juste à créer les styles pour chaque étape de cette transition, et on fait absolument ce qu’on veut : flip en 3D, translation…
  Nb : il n’est pas toujours nécessaire d’avoir des styles pour toutes les étapes, ça dépend de ce qu’on veut.

  <span class="CodeRay"><span class="class">.ajax-transition-mojito</span><span class="class">.ajax-loading-beforeleaving</span> {<span class="error">…</span> }
  <span class="class">.ajax-transition-mojito</span><span class="class">.ajax-loading-isleaving</span> {<span class="error">…</span> }
  <span class="class">.ajax-transition-mojito</span><span class="class">.ajax-loading-afterleaving</span> {<span class="error">…</span> }
  // <span class="tag">etc</span>.
  </span>
  Download

  Et donc pour la transition par défaut, il y aurait son équivalent en CSS fourni par Spip, avec l’opacité à 50% etc.
  Et personnalisable facilement également si on le souhaite.

• Evolution #3953: formulaire de date sur les rubriques

  12 February 2021, by RastaPopoulos ♥

  Dans tous les cas il me semble nécessaire de pouvoir agir sur les dates des objets, sachant qu’historiquement les dates des rubriques sont liées automatiquement à la date de leur dernier article, faudrait-il trouver une solution pour bloquer/débloquer cet automatisme ?

  1) Les dates des rubriques sont liés aux articles, mais il me semble que soit la doc n’est pas assez explicite, soit le code ne va pas jusqu’au bout (mais ça impliquerait possiblement des trop gros tests). En effet, la date des rubriques n’est pas liée vaguement à la date du contenu le plus récent publié dedans. :) C’est plus fourbement précis : c’est la date du dernier contenu dont le statut a été mis en publié pendant qu’il était dans cette rubrique. Et ça à défaut de changer le code pour l’instant, il faudrait au moins le dire moins sibyllin. Concrètement ça signifie que si on déplace un article (publié bien sûr) depuis une autre rubrique dedans après coup, avec une date plus récente, ça ne change rien à la date de la rubrique (dont le contenu a pourtant changé toute autant qu’en publiant direct depuis dedans). En théorie il faudrait que ça change en cascade la date de tous les parents quand on déplace un article (la rubrique de destination et toute la hiérarchie). Et possiblement d’autres cas de ce genre.

  2) Quoiqu’il en soit, même s’il y a un changement de date par défaut, je pense aussi qu’il faut pouvoir décider qu’on veut la changement manuellement après coup. Si on a une liste de rubriques "par date de contenu récent", on peut rien corriger actuellement si les dates ne vont pas. Là j’ai le cas après une migration WP par exemple.

  En attendant faudrait un mini plugin tout simple pour ajouter le form de date sur les rubriques comme le montre touti au début. Mais est-ce ça devrait pas être natif directement ?