Est-ce qu'il serait possible d'ajouter un filtre qui serait appelé dans la
recup_saisie, de sorte à faire des vérifications de cohérence (pour les
champs de type email ou date par exemple) ou plus simplement exploiter les
données dans une fonction externe qui serait placée dans le fichier
mes_fonctions.
Exemple pour ce que je veux faire: créer automatiquement un forward vers un
email saisi dans un extra (avec un autre champ extra case à cocher "je
souhaite un forward") ou gérer une inscription à une mailinglist, grace à
l'interface soap proposée par mon hébergeur (OVH). On pourrait placer ce
filtre juste après le filtre d'affichage, et les séparer par une virgule, ce
qui ne change pas la syntaxe d'utilisation actuelle.
Pour l'internationalisation des listes j'ai pensé à une utilisation de la
forme:
fr{choix 1,choix 2,choix 3},en{1st choice,2nd choice,3rd choice}
et si il n'y a qu'une langue alors on ne mets pas d'accolade
je pense que c'est pas trop dur à coder (je rappelle que je ne code
qu'occasionnellement mais je pense que c'est à ma portée mais ça serait sympa
de me dire de suite comment on récupère la langue que je n'ai pas à
chercher).
enfin pour les choix multiples je vais le coder avec des cases à cocher
- affichage des cases = pas de pb
- récup des données = beaucoup plus chaud mais je trouverai une solution
Personne n'a réagi à ma proposition (et aussi ma question au sujet des
langues) et je n'ai pas eu beaucoup de temps la semaine dernière mais j'en ai
trouvé suffisament pour faire toutes les types de formulaire extra.
Voici donc le fichier en question.
Il ne me reste qu'à voir pour gérer les langues en utilisant des accolades
(ex: fr{texte_fr},en{texte_en})
je n'ai pas eu beaucoup de temps la semaine dernière mais j'en ai
trouvé suffisament pour faire toutes les types de formulaire extra.
Bravo, et merci
Voici donc le fichier en question.
Je viens de tester, (personne n'avait testé ou bien ?)
J'ai un peu corrigé des coquilles et du texte (fichier joint).
Il reste une erreur avec les check-box.
Lorsqu'on décide de restreindre un champs de type case à un secteur pour les articles, alors le champ est tout de meme rempli avec la valeur "false" pour les articles des autres secteurs. (il ne devrait pas)
Un effet de bord aussi :
[(#EXTRA|nom_champs)] n'affiche rien pour les champs de type multiples.
Pour l'internationalisation des listes j'ai pensé à une utilisation de la
forme:
fr{choix 1,choix 2,choix 3},en{1st choice,2nd choice,3rd choice}
et si il n'y a qu'une langue alors on ne mets pas d'accolade
Oui ca peut etre une bonne idée pour rester simple, tu as avancé ?
Justement les valeurs ne servent à rien (pas plus pour les radios que les
listes) donc on crée des valeurs automatiques, c'est mieux on a pas à s'en
soucier.
Justement les valeurs ne servent à rien (pas plus pour les radios que les listes) donc on crée des valeurs automatiques, c'est mieux on a pas à s'en soucier.
Ok, j'ai repris le code pour permettre les deux. Si on ne précise pas de valeurs, alors les valeurs sont les noms des choix, sinon les valeurs sont distinctes. Comme ca tout le monde est content.
Ci joint la version de inc_extra modifié qui gère en plus d'avant des formulaires sous la forme de :
Je pense que ca suffira pour faire tout ce qu'on attend habituellement des extras.
Cette nouvelle version des extras permet aussi d'envisager le choix des squelettes à redirection, les accès restreints simples, les pseudo dates en plus sur les articles, tout ce qu'on aime quoi :))).