Les articles publiés sur le site
-
20 juillet 2019, par maieul@…
— Log
Une branche pour travailler la rééecriture de la partie JS des
afficher_si. L'idée étant d'avoir un seul script unique, quelque soit le
formulaire, qui tire ses infos depuis le data-afficher-si.
Intérêts :
- gain de performance
- un seul js en cache
- moins de ligne de code
- on pourra faire les tests conditionnel uniquement pour le champ qui
vient de changer, et pas pour tout les champs
- gain de lisibilité de code
- possibilité de créer des tests unitaires
- uniformisation de la syntaxe entre la version PHP et la version JS, en
utilisant le même parseur
- a terme, possibilité d'ajouter deux fonctionnalités :
- MATCH pour des regexp
- TOTAL() pour le nombre de case cocher sur des checkbox multiple
L'objectif de cette branche est déjà la réécriture à fonctionnalité
constante. On mergera (ou plutôt rebasera) dans master/trunk après
retour des gens.
-
18 juillet 2019, par maieul@…
— Log
afficher_si : ajouter automatiquement une classe pour savoir si
masqué/visible en fonction d'un affichage conditionnel.
-
17 juillet 2019, par maieul@…
— Log
Constructeur de formulaire. Il peut arriver, pour des raisons
historiques, que des saisies n'aient pas d'identifiant (@). Dans ce cas,
on les génère au moment du chargement du constructeur, avec
saisies_generer. Note : cela ne génère que pour les saisies qui n'ont
pas encore d'identifiant, et cela s'assure que l'identifiant est unique.
-
12 juillet 2019, par cedric@…
— Log
utiliser un filtre pour poser la classe ou les classes qui dependent du type de saisie, c'est plus souple et extensible. On en profite pour ajouter une classe editer_even/editer_odd sur les saisies visibles (ie pas les hidden) car nospam ajoutant un .editer cache, aleatoirement quelque part dans le formulaire, on ne peut pas utilise le classique :nth-child(2n+1) pour faire le job
-
9 juillet 2019, par rastapopoulos@…
— Log
Mais ça n'en finira donc jamais cette saisie jour_mois_annee pourrie…
