#200 Ajout possiblité de personnaliser forumaire info membre selon pays

Ouvert
josue veut fusionner 2 commits à partir de josue/country_settings vers FFDN/master
josue a commenté il y a 6 ans
Il n'existe pas encore de contenu.
jocelyn a commenté il y a 6 ans
Propriétaire

Merci pour la contrib, vous êtes la première incursion de coin hors de France, vive SwissNeutral \o/.

Quelques retours :

Sur le champ de Model

Ça n'est pas possible de mettre un max_length qui dépende d'une clef de conf, ça ne va pas être raccord avec les migrations / état de la DB. Le fait que le schéma de la db varie en fonction d'un paramètre semble casse-gueule.

Par contre ce qui serait possible serait de mettre dans le models.py un champ (ModelField) de zipcode générique, c'est à dire suffisamment grand pour accueillir le zipcode de n'importe quel pays (à la louche 12 caractères ça doit être OK). Puis de faire différer le form field utilisé selon le pays.

Ça demanderait :

  1. De créer un champ de db custom genre AdaptableZipCodeField qui aille chercher via un paramètre en conf, quel « form field » utiliser pour les zipcodes. 

Une idée serait d'utiliser django-localflavor, qui propose (entre autres) des form fields pour valider les zipcodes suisses et français. django-localflavor est déjà dans nos dépendances, donc c'est pas plus cher :-). En bonus, on ferait une validation plus fine que simplement le nombre de caractères.

https://docs.djangoproject.com/en/1.9/howto/custom-model-fields/#specifying-the-form-field-for-a-model-field

Pour aller plus loin

En pensant un peu plus loin (pas nécessairement dans cette PR), je pense que l'on pourrait utiliser un paramètre genre COUNTRY qui groupe un peu les paramètres de localisation autres que la langue. (on pourrait reprendre les code pays utilisés par django-localflavor par ex).

Bref…

Je ne peux pas fusionner en l'état, au plaisir de poursuivre l'échange !

Merci pour la contrib, vous êtes la première incursion de coin hors de France, vive SwissNeutral \o/. Quelques retours : ## Sur le champ de Model Ça n'est pas possible de mettre un `max_length` qui dépende d'une clef de conf, ça ne va pas être raccord avec les migrations / état de la DB. Le fait que le schéma de la db varie en fonction d'un paramètre semble casse-gueule. Par contre ce qui serait possible serait de mettre dans le *models.py* un champ (ModelField) de zipcode générique, c'est à dire suffisamment grand pour accueillir le zipcode de n'importe quel pays ([à la louche](https://fr.wikipedia.org/wiki/Code_postal) 12 caractères ça doit être OK). Puis de faire différer le *form field* utilisé selon le pays. Ça demanderait : 1. De créer un champ de db custom genre `AdaptableZipCodeField` qui aille chercher via un paramètre en conf, quel « form field » utiliser pour les zipcodes.  Une idée serait d'utiliser *django-localflavor*, qui propose (entre autres) des form fields pour valider les zipcodes [suisses](https://django-localflavor.readthedocs.io/en/latest/localflavor/ch/) et [français](https://django-localflavor.readthedocs.io/en/latest/localflavor/ch/). *django-localflavor* est déjà dans nos dépendances, donc c'est pas plus cher :-). En bonus, on ferait une validation plus fine que simplement le nombre de caractères. https://docs.djangoproject.com/en/1.9/howto/custom-model-fields/#specifying-the-form-field-for-a-model-field ## Pour aller plus loin En pensant un peu plus loin (pas nécessairement dans cette PR), je pense que l'on pourrait utiliser un paramètre genre `COUNTRY` qui groupe un peu les paramètres de localisation autres que la langue. (on pourrait reprendre les code pays utilisés par django-localflavor par ex). ## Bref… Je ne peux pas fusionner en l'état, au plaisir de poursuivre l'échange !
josue a commenté il y a 6 ans
Publier

Merci pour ta relecture

Ça n'est pas possible de mettre un max_length qui dépende d'une clef de conf, ça ne va pas être raccord avec les migrations / état de la DB.

Ca m'étonne pas. J'ai d’ailleurs presque été étonné de voir que django acceptait cela...

Je vais voir tous cela. C'est vrais que ca serait bien de peut être avoir vue plus globale du problème avec un paramètre country. Ca permettrait aussi d'y intégrer la gestion de la monnaie pour pouvoir utiliser une autre monnaie que l'euro.

Après la question que je me pose c'est que typiquement dans notre cas en Suisse on peut être aussi pouvoir supporter des codes postaux français (dans le cas d'un adhérent qui à une adresse en France). Donc je pense il faut bien réfléchir à la question.

Merci pour ta relecture > Ça n'est pas possible de mettre un `max_length` qui dépende d'une clef de conf, ça ne va pas être raccord avec les migrations / état de la DB. Ca m'étonne pas. J'ai d’ailleurs presque été étonné de voir que django acceptait cela... Je vais voir tous cela. C'est vrais que ca serait bien de peut être avoir vue plus globale du problème avec un paramètre country. Ca permettrait aussi d'y intégrer la gestion de la monnaie pour pouvoir utiliser une autre monnaie que l'euro. Après la question que je me pose c'est que typiquement dans notre cas en Suisse on peut être aussi pouvoir supporter des codes postaux français (dans le cas d'un adhérent qui à une adresse en France). Donc je pense il faut bien réfléchir à la question.
jocelyn a commenté il y a 6 ans
Propriétaire

Après la question que je me pose c'est que typiquement dans notre cas en Suisse on peut être aussi pouvoir supporter des codes postaux français (dans le cas d'un adhérent qui à une adresse en France). Donc je pense il faut bien réfléchir à la question.

OK, on peut aussi le gérer de manière feignante genre « un code postal c'est une suite de nombres entre 4 et 12 caractères »… (on passe le champ sur le modèle à max_length=12 et on met un petit RegexValidator('\d{4,12}') comme validateur du champ). Moi je crois que ça m'irait.

> Après la question que je me pose c'est que typiquement dans notre cas en Suisse on peut être aussi pouvoir supporter des codes postaux français (dans le cas d'un adhérent qui à une adresse en France). Donc je pense il faut bien réfléchir à la question. OK, on peut aussi le gérer de manière feignante genre « un code postal c'est une suite de nombres entre 4 et 12 caractères »… (on passe le champ sur le modèle à `max_length=12` et on met un petit `RegexValidator('\d{4,12}')` comme validateur du champ). Moi je crois que ça m'irait.
josue a commenté il y a 6 ans
Publier

Moi je pense aussi que ça irait.

Moi je pense aussi que ça irait.
jocelyn a commenté il y a 6 ans
Propriétaire

@josue hésite pas à éditer ta PR avec cette logique si tu en trouves le temps :-)

@josue hésite pas à éditer ta PR avec cette logique si tu en trouves le temps :-)
jocelyn a commenté il y a 5 ans
Propriétaire

@josue bump ?

@josue bump ?
jocelyn a commenté il y a 5 ans
Propriétaire

(nb: il faut refaire la MR sur code.ffdn.org qui est passé à gitlab)

(nb: il faut refaire la MR sur code.ffdn.org qui est passé à gitlab)
Cette pull request peut être fusionnée automatiquement.
Connectez-vous pour rejoindre cette conversation.
Aucun jalon
Pas d'assignataire
2 Participants
Chargement…
Annuler
Enregistrer
Il n'existe pas encore de contenu.