Sur d’autres sites (6531)

• Nomenclature #4626 : Renommer le menu "Squelettes"

  30 avril 2021, par b b

  FTR, un grep uniquement dans les plugins de la zone car ça serait trop facile de le faire dans les squelettes :p

  rgrep ’parent="menu_squelette’ .
  ./sociaux/paquet.xml :    
  ./eva-web-bonus/paquet.xml :    
  ./tooltip/paquet.xml :    
  ./seo/paquet.xml :    
  ./chosen/paquet.xml :    
  ./mathjax/paquet.xml :    
  ./eva-web-habillage/paquet.xml :    
  ./switcher/paquet.xml :    
  ./menus/paquet.xml :    
  ./squelettes_par_mots_cle/paquet.xml :    
  ./eva-web-install/paquet.xml :    
  ./champs_extras_synchronisation/paquet.xml :    
  ./fontawesome5/paquet.xml :    
  ./picto/paquet.xml :    
  ./videos/paquet.xml :    
  ./exclure_secteur/paquet.xml :    
  ./timecircles/paquet.xml :    
  ./comarquage/paquet.xml :    
  ./player/paquet.xml :    
  ./menu_langues_liens/paquet.xml :    
  ./sjcycle/paquet.xml :    
  ./skeleditor/paquet.xml :    
  ./zinit/paquet.xml :    
  ./comments/paquet.xml :    
  ./noizetier/paquet.xml :    
  ./elements/paquet.xml :    
  ./w3css/paquet.xml :    
  ./kaye/paquet.xml :    
  ./refbase/paquet.xml :    
  ./xray/paquet.xml :    
  ./adaptive_images/paquet.xml :    
  ./dublin_core/paquet.xml :    
  ./acs/paquet.xml :    
  ./eva-web-mentions/paquet.xml :    
  ./porte_plume_enluminures_typographiques/paquet.xml :    
  ./forkawesome/paquet.xml :    
  ./campagnes/paquet.xml :    
  ./recherche_mots_cles/paquet.xml :    
  ./compositions/paquet.xml :    
  ./rainette/paquet.xml :    
  ./slick/paquet.xml :    
  ./spip_visuels/paquet.xml :    
  ./seminaire/paquet.xml :    
  ./mediaspip_player/paquet.xml :    
  ./cloudzoom/paquet.xml :    
  ./select2/paquet.xml :    
  ./links/paquet.xml :    
  ./court-circuit/paquet.xml :    
  ./saisies/paquet.xml :    
  ./xiti/paquet.xml :    
  

  Permet de relever que certains plugins qui n’ont rien à voir avec la mise en page ou la présentation tapent l’incruste dans ce menu, il sera bon de leur changer de catégorie une fois le changement appliqué.

  Juste pour rire, qu’est-ce que seo, champs_extras_synchronisation, xiti, etc foutent la dedans ? ^^

• Evolution #3801 (Nouveau) : Filtrage des boucles DATA selon des contenus divers, et extension des ...

  2 juillet 2016, par marcimat ☺☮☯♫

  Je suis tombé sur un cas de boucle DATA qui m’a ennuyé car le filtrage que je souhaitais n’était pas directement possible actuellement avec les critères dont on dispose.

  Soit le tableau, disons #TAB suivant :

  $tab = [
      [ ’id’ => 1, ’mots’ => [ 11, 120, 53 ]],
      [ ’id’ => 2, ’mots’ => [ 32, 11, 20 ]],
      [ ’id’ => 3, ’mots’ => [ 11, 78, 34 ]],
      [ ’id’ => 4, ’mots’ => [ 120, 26, 91 ]],
  ] ;
  

  
  Je souhaitais boucler sur les éléments ayant le mot 11 par exemple, dans la clé ’mots’.
  De base la boucle serait :

  #ID 
  
  

  Il faudrait ajouter un critère pour restreindre aux seuls éléments contenant le mot 11, mais {mots = 11} ne va pas, ni {mots IN 11} vu que c’est le champ "mots" qui est un tableau.
  On pourrait imaginer pouvoir écrire {11 IN mots} qui serait probablement plus clair, mais ce n’est pas permis.

  Il n’y a actuellement pas moyen de réaliser ce filtre, ni d’étendre simplement les filtres à appliquer.

  On propose ici de réfléchir à éventuellement permettre l’extension de ces tests de validation en fonction des contenus, ce qui s’apparente à ajouter quelque chose dans le WHERE en SQL, mais pour les itérateurs, c’est plutôt ajouter une contrainte sur la méthode valid(). Les critères tel que {id=3} ajoutent déjà des contraintes, même {chemin/du/tableau > 5} fonctionne.

  Une idée serait d’ajouter un critère {filtre NN} ou {valider NN} et de définir une fonction NN() dans son code (mes_fonctions.php par exemple) qui recevrait la clé et la valeur en cours de validation et retournerait true ou false pour indiquer si cette entrée est acceptée ou pas. La fonction à créer serait au minimum donc NN($cle, $valeur) { return true; }

  On pourrait transmettre des paramètres supplémentaires, tel que {filtre nom, p1, p2} qui arriveraient dans un tableau d’arguments en 3è paramètre : NN($cle, $valeur, $args).

  Voici un diff qui permet :
  1) de prendre en compte `$command[’filtres’]` dans les itérateurs. Chaque entrée de ce tableau est un tableau décrivant 1 filtre, avec comme premier élément le nom de la fonction à appeler, et les suivants les éventuels arguments.
  2) de déclarer un critère `filtre` sur les boucles DATA qui remplissent ce tableau de filtres
  3) de montrer un exemple d’un filtre (mal nommé) ’contient’ avec 2 arguments

  Index : public/iterateur.php
  ===================================================================
  
  — - public/iterateur.php    (revision 23091)
  +++ public/iterateur.php    (working copy)
  @@ -300,6 +300,18 @@
              $this->limit = $limit[1] ;
          
  +       // filtres explicites filtre nom_fonction, param, param
  
  +       if (!empty($this->command[’filtres’])) 
  
  +           foreach ($this->command[’filtres’] as $args) 
  
  +               $nom = array_shift($args) ;
  
  +               if (function_exists($nom)) 
  
  +                   $this->filtre[] = $nom . ’( $me->key(), $me->current(), ’ . var_export($args, true) . ’)’ ;
  
  +                else 
  
  +                   spip_log("Filtre d’itérateur non connu : " . (string)$filtre) ; // [todo] mettre une erreur de squelette
  
  +               
  
  +           
  
  +       
  
  +
  

  /**
  
   * Compile le critère `filtre` d’une boucle DATA
  
   * 
  
   * @syntaxe `filtre nom, [arg1, [arg2, [...]]]`
  
   * @example `filtre contient, mots, 3`
  
   *
  
   * @param string $idb Identifiant de la boucle
  
   * @param array $boucles AST du squelette
  
   * @param Critere $crit Paramètres du critère dans cette boucle
  
   */
  
  function critere_DATA_filtre_dist($idb, &$boucles, $crit) 
  
      $boucle = &$boucles[$idb] ;
  
      // créer le tableau de tous filtres de la boucle
  
      $boucle->hash .= "\n\tif (!isset(\$filtres_init))  \$command[’filtres’] = array() ; \$filtres_init = true ; \n" ;
  
      // créer le tableau de ce filtre
  
      $boucle->hash .= "\t\$i = count(\$command[’filtres’]) ; \$command[’filtres’][\$i] = array() ;\n" ;
  
      // ajouter les arguments du filtre
  
      foreach ($crit->param as $param) 
  
          $boucle->hash .= "\t" . ’$command[\’filtres\’][$i][] = ’ . calculer_liste($param, array(), $boucles, $boucles[$idb]->id_parent) . " ;\n" ;
  
      
  
  
  /**
  
   * Conserve les éléments de la boucle dont le chemin indiqué contient une certaine valeur
  
   * sous entendu que ce chemin pointe sur une liste de valeurs possibles
  
   * 
  
   * @syntaxe `filtre contient, chemin, val`
  
   * @example `filtre contient, mots, 3`
  
   * 
  
   * - chemin : est un parcours qui sera fait dans le tableau $valeurs, 
  
   *   chaque / entrant dans un sous élément @see table_valeur()
  
   * - val : est une valeur à trouver dans le tableau retrouvé du chemin indiqué
  
   *   dans l’exemple le chemin ’mots’ retourne pour une entrée une liste tel que `array(12, 31, 21)`
  
   * 
  
   * @param int|string $cle Clé analysée
  
   * @param mixed $valeur Valeur analysée
  
   * @param array $args Arguments passés au filtre
  
   * @return bool True pour accepter cette entrée, false sinon.
  
  **/
  
  function contient($cle, $valeur, $args) 
  
      if (count($args) != 2)  
  
          return false ;
  
      
  
      list($chemin, $val) = $args ;
  
      if ($valeurs = table_valeur($valeur, $chemin)) 
  
          return in_array($val, $valeurs) ;
  
      
      return false ;
  
  
  

  Et un exemple d’utilisation en squelettes

  Test
  #SETobjets,#LISTE
  
  #SETobjets,#GETobjets|push#ARRAYid,1,mots,#LISTE10,11,12
  
  
  #SETobjets,#GETobjets|push#ARRAYid,2,mots,#LISTE30,31,32
  
  
  #SETobjets,#GETobjets|push#ARRAYid,3,mots,#LISTE50,51,52
  
  
  #SETobjets,#GETobjets|push#ARRAYid,4,mots,#LISTE32,11
  
  
  #SETobjets,#GETobjets|push#ARRAYid,5,mots,#LISTE52,10
  
  
  #SETid,32
  #ID
  
  

  À réfléchir…

• Evolution #4148 : Augmenter la largeur de l’espace privé

  23 juin 2018, par tcharlss (*´_ゝ｀)

  Hop, j’ai pu tester un peu le remix (j’en ai profité pour piquer quelques trucs au passage ^^).

  1ère impression très sympa avec la largeur augmentée, la police plus grande, et les autres détails.
  Je ne vais commenter que ces 2 premiers points et le layout (ces 3 points étant liés), pour ne pas qu’on sorte du sujet du ticket.

  (...) pour que la colonne #extra soit sous la #navigation en dessous d’une certaine largeur, et qu’elle passe à droite au delà

  3 fois oui, comme ça le layout s’adapte à la largeur de l’écran. La colonne de droite peut avoir son utilité, c’est très bien qu’elle soit affichée quand il y a la place.
  Dans le trunk c’est sur ça que je suis parti.

  Toujours sur le layout, il y a un point qui me semble important, c’est qu’en absence de contenu dans une colonne, les autres doivent remplir l’espace libéré.
  Par exemple sur la page des articles, où on a une grande marge vide à gauche actuellement.
  Ça c’était la 2ème raison principale du plugin, et on a perdu ça dans le remix apparemment.
  La difficulté, c’est qu’on ne peut pas poser de taille directement sur une colonne #navigation ou #extra, car elles sont toujours présentes même si elles sont vides. Et même à coup de flex-shrink puissance 10, c’est très compliqué d’avoir la main sur leur taille du coup.
  J’ai contourné le problème en posant la largeur sur le contenu direct de ces colonnes , jusqu’à présent je n’ai pas constaté de dommage collatéral :
  

  #navigation > .ajaxbloc > *,
  #navigation > :not(.ajaxbloc),
  #extra > .ajaxbloc > *,
  #extra > :not(.ajaxbloc) 
        width : calc(8em + 12vw) ;
  
  

  La taille de police augmentée, très bien, c’est plus lisible et agréable.
  Je pense qu’elle pourrait être un brin responsive, c’est à dire partir d’une base un peu moins grande et augmenter proportionnellement à la largeur de l’écran.
  Dans le trunk je teste cette règle qui donne 14px à la base, et 15px en 1920px par ex. : font-size: calc(0.8em + 0.133vw);
  Un dommage collatéral quand même : on perd un peu de la place libérée avec la nouvelle largeur, mais c’est un mal nécessaire.

  Et donc j’en viens au truc principal : la largeur.
  Bon, si on part sur du 1200px, ce sera déjà une bonne avancée, je ne vais pas me plaindre. Allez, tant qu’à faire on peut pousser vers 1400px ?

  Mais d’une façon générale, je reste persuadé qu’à terme, la pleine largeur est la meilleure option pour une interface (et là je peux reprendre la citation de Coluche à mon compte si j’ai bien compris ?).
  C’est du coup un peu plus compliqué que de mettre un witdh: 100% au conteneur général d’un coup de baguette magique, en fait il y a finalement pas mal de choses concomitantes à régler (plus que ce que j’imaginais à la base).
  Notamment la taille de la police, en augmentant comme dans le remix de nicod_, c’est déjà beaucoup plus équilibré.
  Après d’une façon générale, il faut que cette largeur soit bien exploitée. Là on part d’une interface où les contenus ont été pensés pour rentrer dans du 780px de large, donc forcément au départ il y aurait des choses un peu bancales, quelques pages déséquilibrées. Mais dans l’ensemble je suis sûr qu’on y gagnerait à terme et ça poserait les bases pour la suite.

  Enfin, il y a un point que je veux souligner, parceque je ne suis pas du tout d’accord avec certaines remarques : la proposition de pleine largeur n’est pas une préférence esthétique, c’est un besoin imposé par le contenu.
  C’est ça la demande à la base pour ce ticket, le but est de parvenir à « faire rentrer » du contenu qu’il est difficile de placer actuellement.
  Ne pas en avoir « l’utilité » personnellement certes, mais il y a tout un écosystème de plugins avec des besoins divers pour lesquels ça devient nécessaire.