[Corrigé] Fiche modification/ajout

[yip]

En passant au système MVC, j'ai du changer la page de modif/ ajout de point.
Il y a de bugs:

-les coordonnées Latitude et Longitude ne sont plus visible, et ne sont plus mises a jour quand on change de Systeme Degrés, Lambert ... J'ai beau chercher, toujours rien pour l'instant

-Les champs, surtout au debut de la page, se marchent les uns sur les autres sans que ce soit bien clair

-Quand l'etat de la cabane est inconnu, ce n'est pas affiché (mais c'est correctement enregistré en base)

-Pas testé la duplication

[Dominique]

On a effectivement perdu les caractères accentués en UTF8 (il y en a d'autres)
Le coup du GIT qui ne transmet pas les encodages de fichiers
Il faut vraiment purger ce pb

Question : est ce qu'il n'y a que le commit Tortoise qui fait ça ou est aussi le cas du commit unix ?

Je ne vois pas de champs qui se marchent dessus

[yip]

Je ne vois pas de champs qui se marchent dessus

C'est fouilli en fait. on sait plus trop a quel champs est associé tel libéllé ...
Comme la structure sémantique est a peu près bonne, ca va se regler en CSS (le - possible bien sur).
Si tu as une idée sur la disparition des champs Latitude/Longitude (par JS d'OL) je suis preneur.

Question : est ce qu'il n'y a que le commit Tortoise qui fait ça ou est aussi le cas du commit unix ?

sur la prod, tous les fichiers sont en UTF8, dans tous les repertoires (a par 2 ou 3 bricoles simples)

file -i modeles/*
modeles/config.php: text/x-php; charset=utf-8
<. je met pas tout hein ..>
modeles/fonctions_points.php: text/x-php; charset=utf-8
modeles/fonctions_polygones.php: text/x-php; charset=utf-8
modeles/fonctions_pubs.php: text/x-php; charset=utf-8
<...>

sauf dans le repertoire OL:

file -i ol2.12.dc/*
ol2.12.dc/licenses.txt: text/plain; charset=iso-8859-1
ol2.12.dc/OpenLayers.js: text/plain; charset=iso-8859-1
ol2.12.dc/proj4js-1.1.0: inode/directory; charset=binary
ol2.12.dc/proxy.php: text/x-php; charset=iso-8859-1
ol2.12.dc/README.md: text/html; charset=iso-8859-1
ol2.12.dc/refuges-info-sld.xml: application/xml; charset=us-ascii

Comme Sly dit que GIT ne s'occupe pas d'encodage,
Il semblerait que ca vienne de tortoise

[sly]

De cette lecture où je ne suis pas sûr de comprendre exactement de quoi il retourne je retiens une seule chose :
Personne ne doit faire un "git pull" en prod c'est ça ? ;-)

Mais je crois que mon appel est arrivé trop tard, je constate que le formulaire pour modifier un point ou en ajouter un n'est pas fonctionnel.

Je suggère :
1) un retour arrière sur la prod
2) à l'avenir de se concerter avant de faire une mise en live de la version "master"

What do you think ?

[Dominique]

J'ai vu le bug.
Est ce que je peux mettre la modif sur GIT et faire GIT PULL sur la prod sans tout casser ?

[sly]

D'après : https://github.com/sletuffe/www.refuges ... its/master

et "git log" sur la prod, le www est actuellement synchro avec master, donc, tu peux ajouter ta correction et faire un git pull, ça devrait marcher.

L'autre solution restant celle que j'évoquais, faire revenir www vers une version stable, et continuer nos modifs tranquillement jusqu'a ce que ça nous convienne.

Pour ça, ça va pas mal dépendre des modifs faites sur la base de donnée s'il y en a eu

[Dominique]

Je propose plutôt de stabiliser ce qu'on a aujourd'hui
Je ne sais pas de quand date ce problème et nous avons en corrigé pas mal d'autres depuis. Il serait dommage de revenir en arrière
Egalement, de corriger le plus rapidement tout pb se présentant

Par contre, il faudrait peut être se calmer sur les innovations !
Le but premier du site, c'est de référencer les refuges

[sly]

A nous de trouver le juste milieu.

WRI a un peu toujours évolué avec les utilisateurs qui nous aident dans la recherche de bugs, c'est une manière de fonctionner.

Et il y a des cas de figure plus problématiques que d'autres :
- une recherche qui cherche mal, pas dramatique, quelqu'un le remarque et on répare
- une saisie qui marche mal, ça peut conduire à des données foireuses en base

Et pour ce cas, ça vaut peut-être le coup de rester en test quelques temps le temps que 2 développeurs tentent de cocher dans tous les sens voir si on repère un problème.

En ce moment on fait un peu des deux : corriger des bugs, apporter du nettoyage interne et des fonctionnalités
Forcément, c'est un peu plus délicat.

Mais en même temps, des bugs, y'en a plus tant que ça non ?


Enfin bref, tout ça pour dire que je parle dans le vent et je n'ai pas de solution, j'écoute pour une fois ;-)

[Dominique]

Voilà.
J'ai refait marcher le formulaire modification
Le HTML était complètement modifié, malheureusement, ce HTML est manipulé par le JS DomElement pour afficher les coordonnées en différentes types de coordonnées et pour que le déplacement du curseur soit pris en compte dans le formulaire. Il faut donc le manipuler avec précaution.

Je propose de geler les évolutions jusqu'à ce que le site soit stable (1 à 2 semaines)
Puis de forker à partir de là, évoluer comme on veut et de tester à donf la branche avant de remettre en prod
Evidemment, pendant cette phase, si un bug urgent venait à être corrigé, il faudrait le reporter sur la branche
Je ne vois pas d'autres méthodes.
Je pense que nous devons bien ça à ceux qui veulent utiliser le site pour des raisons montagnardes

[yip]

Le HTML était complètement modifié

Désolé, Vous savez comment le PHP et le HTML etaient imbriqués.
pour faire du MVC, a un moment ou un autre, j'ai refait le HTML. en essayant de rester dans le même rendu bien sûr. 0 ajout de fonctionnalité, plutôt de la ré-écriture.

est manipulé par le JS DomElement pour afficher les coordonnées en différentes types de coordonnées et pour que le déplacement du curseur soit pris en compte dans le formulaire. Il faut donc le manipuler avec précaution.

Dominique, tu as fait comment pour le JS ? ça m'interesse, j'ai cherché pendant 2 ou 3 heures, pourtant bien fait gaffe de conserver les même ID.
Le script ne se base pas sur les IDs comme par exemple OL ?

On dirait qu'on va passer a un mode de développement professionnel ...

[Dominique]

Dominique, tu as fait comment pour le JS ? ça m'interesse, j'ai cherché pendant 2 ou 3 heures, pourtant bien fait gaffe de conserver les même ID.
Le script ne se base pas sur les IDs comme par exemple OL ?

On dirait qu'on va passer a un mode de développement professionnel ...

Le point crucial était que les suisses ne nomment pas les coordonnées longitude & latitude mais X & Y
Donc je fais un innerHTML sur le <label id="titre-lon">
Il ne faut donc pas mettre le <input /> à l'intéreur de la balise sous peine de se faire effacer

Je reconnais que ce n'est pas documenté

Le code est dans:
http://www.refuges.info/ol2.12.4/lib/Op ... osition.js / drawValues: function () {...}

On X-Chat ce soir sur la stabilité / évolutions du site ?

[sly]

Je propose de geler les évolutions jusqu'à ce que le site soit stable (1 à 2 semaines)
Puis de forker à partir de là, évoluer comme on veut et de tester à donf la branche avant de remettre en prod
Evidemment, pendant cette phase, si un bug urgent venait à être corrigé, il faudrait le reporter sur la branche
Je ne vois pas d'autres méthodes.
Je pense que nous devons bien ça à ceux qui veulent utiliser le site pour des raisons montagnardes

On dirait qu'on va passer a un mode de développement professionnel ...

Je suis partagé en deux : d'un coté, je suis bien en phase avec ce qu'a dit dominique :
* un peu plus de prudence afin d'avoir un www.refuges.info qui marche pour les fonctionnalités disons "un peu plus importantes", et un peu plus de concertation préalable. Ayant la quasi totalité du pourquoi le code est comme ça dans son "coeur" dans ma tête je peux presque à chaque fois me souvenir et ça permet de mieux voir comment améliorer en tenant compte du pourquoi c'est là.

* D'un autre coté, vu comment certains galèrent avec git, si on inclus des branches, ou si on créé une deuxième zone pas vraiment synchro dont on copie les modifs manuellement, j'ai peur que ça décourage un peu ou complètement nos valeureux développeurs et/ou qu'on finisse par se marcher encore plus dessus et perdre du code à la fin.

En tout cas, ok pour le blabla de soir genre 19h00 et + et tenter de concilier nos attentes, trouver un terrain et une méthode qui n'en frustre ni les uns, ni les autres.

Car je ne sais pas si je tiendrais 2 semaines sans avoir envie de coder une évolution ;-)

[Dominique]

En tout cas, ok pour le blabla de soir genre 19h00

Dernière minute: désolé, ça ne sera pas ce soir plus dispo.