« Module:Biblio/Commun » : historique des versions

(les plus récentes | les plus anciennes) Voir (50 plus récentes | ) (20 | 50 | 100 | 250 | 500)

6 juillet 2021

4 juillet 2021

26 mars 2021

  • actudiff 12:3026 mars 2021 à 12:30w>Od1n 20 564 octets +24 mettons-nous à la place du visiteur ayant les textes à la place des images ; ce qui nous intéresse en l'occurrence avec cette image, ce n'est pas sa description, mais l'information qu'elle communique

25 mars 2021

18 juin 2020

  • actudiff 07:5118 juin 2020 à 07:51w>Od1n 20 515 octets +9 eu égard que les paramètres sont trimmés en amont : optimisations, en utilisant des codes plus légers
  • actudiff 06:4718 juin 2020 à 06:47w>Od1n 20 506 octets −26 optimisation : la capture est toujours présente, c'est simplement qu'elle peut être vide
  • actudiff 06:4318 juin 2020 à 06:43w>Od1n 20 532 octets 0 au cas où il y aurait plusieurs espaces d'affilée, on rencontre ça parfois… c'est la faute au clavier
  • actudiff 04:5318 juin 2020 à 04:53w>Od1n 20 532 octets 0 utilisation de la fonction Commun.validTextArg() optimisée de ce même module (refs 105796198) ; refs à propos l'introduction de ce code : 115647067
  • actudiff 04:0518 juin 2020 à 04:05w>Od1n 20 532 octets −24 la fonction Commun.validTextArg() étant prévue pour des paramètres nommés provenant de modèles, et ces paramètres étant trimmés en amont, une chaîne avec seulement des espaces est trimmée en une chaîne vide, et le test "match('%S')" est donc inutile (sous réserve que la fonction ne soit pas utilisée en dehors de son domaine d'application, mais dans ce cas c'est à ce niveau qu'il faut corriger)

16 juin 2020

15 juin 2020

27 mai 2020

30 mars 2020

23 novembre 2019

3 octobre 2019

29 septembre 2019

12 septembre 2019

8 septembre 2019

6 août 2019

4 août 2019

30 juillet 2019

  • actudiff 22:0430 juillet 2019 à 22:04w>Od1n 20 945 octets −13 même ça c'était en trop : on peut avoir seulement l'année : on a toujours le "t == true" pour savoir si le parsage a réussi ; donc on a maintenant le balisage, et homogénéité résultats entre "année=2015" et "date=2015"
  • actudiff 21:5730 juillet 2019 à 21:57w>Od1n 20 958 octets −63 empêchait le support (balisage) avec "mois-mois" (refs 161412279) (et peut-être d'autres à l'avenir), et de toute façon était redondant : si le module Date retourne un mois c'est qu'il l'a reconnu, en plus il retourne "t == true", et autrement une erreur est produite
  • actudiff 07:1930 juillet 2019 à 07:19w>Od1n 21 021 octets +27 per MDN, si l'attribut "datetime" est omis, c'est le contenu du node qui est utilisé comme valeur "machine-readable", et là ça peut être un peu n'importe quoi, sauf une valeur valide…
  • actudiff 07:0330 juillet 2019 à 07:03w>Od1n 20 994 octets −21 sauf omission de ma part, ce "nocat" n'est pas nécessaire (peut-être un overlook), car si on arrive ici c'est que le parsage de la date a réussi
  • actudiff 06:3730 juillet 2019 à 06:37w>Od1n 21 015 octets −28 nom d'attribut "datevalue" incorrect (c'est "datetime" + "data-sort-value") ; de toute façon si on arrive ici, c'est que le parsage de la date a échoué (donc pas balisable), mais elle n'est pas forcément erronée (le module Date ne gère pas 100% des cas), et baliser seulement l'année me paraît faux

12 mars 2019

  • actudiff 00:1812 mars 2019 à 00:18w>Od1n 21 043 octets 0 unique utilisation de Date::validationJourMoisAnnee() en mode variadique, qui à son tour est l'unique utilisation de Outils::extractArgs() en mode variadique ; il va donc être possible de simplifier ces méthodes

5 novembre 2018

28 juin 2018

25 avril 2018

16 avril 2018

11 avril 2018

16 mars 2018

22 décembre 2017

1 octobre 2017

30 juillet 2017

(les plus récentes | les plus anciennes) Voir (50 plus récentes | ) (20 | 50 | 100 | 250 | 500)