contact form / localisation + personnalisation

Les différents snippets semblent ne pas êtres conçu pour être aisément traduites...
Me trompai-je ?

J’ai voulu franciser le contactform de base et j’ai du bricoler ds le php (bon ok, c’est pas la mere à boire, mais.. pour un end user ca le fait pas)

1/ Dans chaque snippet il ne devrait pas y avoir des appels relatifs, par variable, à un fichier ’ lang’

2/ Pour personnaliser le contact form : y a t il un manager ou bien c’est tout à la mano dans le code (longueur des champs, listes de choix, etc ..)
Sinon quel gestion de formulaire faut-il utiliser pour un usage plus souple ?

Merci

En parlant de formulaire, Marc s’est mis dessus récemment, et pour ma part, je commence à peine en m’inspirant de l’existant

J’ai un formulaire de contact à réaliser avec des checkbox, je sens que je vais m’amuser ...

As tu essayé eform ?
Il y a également la class makeForm d’opengeek qui est géniale mais demande un temps d’apprentissage.
Toutes ces ressources sont dans le rpository.

:-)

@Perrine : si tu suis effectivement " l’existant " que tu mentionnes pour l’élaboration de ton formulaire, n’hésite pas à me demander pour les checkbox, j’ai eu l’occasion de batifoler avec récemment, je peux donc t’aider à intégrer le code approprié dans le snippet pour ce genre de cas.

Merci beaucoup Moon !

Je commence à peine là, j’en suis à la personnalisation de mon chunk mais je n’hésiterai pas

ok, je vais regarder eform

Oui je suis sur le devlp du snippet ’SendForm’ qui permettra de concevoir un formulaire de contact.
Celui ci intègre un fichier de traduction english, french...

A partir d’un chunk ’ContacForm’ voir d’un fichier spécifique ’contactForm.tpl’ il te sera possible de positionner les champs que tu veux.
Il pourra prendre en compte un ou plusieurs fichiers CSS ou JS.
Pour l’instant le snippet intègre parfaitement ces fichiers et affiche le formulaire.
Je suis à la phase de récupération des champs saisies et des tests de validité de ces champs afin d’afficher un message d’erreur et la liste des champs mal renseignés si besoin.

Puisque je suis dans le code, je vais le poster (coté français puis anglais) pour avoir quelques avis.

De mon côté, en l’attente du sendForm de Marc, je viens de tester eForm et j’ai profité de l’occasion pour ajouter un paramètre $lang. Celui-ci à non seulement pour but de prendre en compte la traduction des messages, mais aussi les tests de validité sur les dates et les nombres. Enfin, j’ai aussi modifié la fonction formMerge(), pour permettre l’insertion dans le sujet du message de données en provenance du formulaire. Vous trouverez ci-joint cette version non encore complètement testée...

Je vois que (peut-être sans le savoir) tu as repris le principe que j’ai utilisé dans SendForm.

En effet le fichier lang permet non seulement de traiter la traduction mais aussi contient sous forme de pattern le code permettant de tester les variables : email, test, etc... (je n’ai pas encore tout intégrer).
Ceci dit si eForm fait la même chose que mon snippet je me pose la question de continuer ou non

En fait dans SendForm j’intégre la possibilité de prendre en compte des fichiers externes comme des fichiers CSS ou JS que ne fait pas pour le moment eForm.

salut marc,

peut etre que tu devrais contacter tobyl pour discuter d’une collaboration pour integrer tes dvpts à l’existant.
cela t’évitera de travailler sur des fonctionnalites existantes d’eform.
:-)